- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Для равномерного распределения 1 млн файлов - берем md5 имени файла.
далее $folder_name = substr(md5($file), 0, 2); (получаем первые 2 знака md5 хеша)
итого получаем 256 директорий, в которых вполне равномерно разместилось по 3800-4100 файлов...
Извините, перепутал окна...
Когда-то был такой сервис - nntp. У него было много файлов. Как решался вопрос хранения: есть один огромный файл, в него последовательно пишутся данные, позиции сохраняются. При достижении конца файла запись начинается сначала, уничтоженные индексы удаляются. Преимущества - максимально плотная упаковка файлов, предсказуемый размер файла на диске, нет фрагментации, доступ к данным быстрый. Вопрос только с индексами - где их хранить можно придумать в зависимости от задачи. Например, в перле 4000000 индексов будут занимать 80 мегабайт плюс длины имён файлов (а имена понятие тут относительное, на них нет ограничений) минимум, ну и плюс ещё сколько-то на упрощения.
Это если нет желания задействовать nginx для отдачи статики
Когда-то был такой сервис - nntp. У него было много файлов. Как решался вопрос хранения: есть один огромный файл, в него последовательно пишутся данные, позиции сохраняются. При достижении конца файла запись начинается сначала, уничтоженные индексы удаляются. Преимущества - максимально плотная упаковка файлов, предсказуемый размер файла на диске, нет фрагментации, доступ к данным быстрый. Вопрос только с индексами - где их хранить можно придумать в зависимости от задачи. Например, в перле 4000000 индексов будут занимать 80 мегабайт плюс длины имён файлов (а имена понятие тут относительное, на них нет ограничений) минимум, ну и плюс ещё сколько-то на упрощения.
Это если нет желания задействовать nginx для отдачи статики
Интересное подобие замены функций файловой системы, но минусы тоже есть,
ненужные файлы помечать свободным пространством в файле, потом всё равно лучше дефрагментация за счёт пересоздания файла и индексов, и есть опасность что всё накроется :)
А так, интересная штука, но на мой взгляд заменяет стандартный уже давно разработанный функционал FS. Наверное плюс в том что все индексы можно хранить в памяти?
PS. у себя на одном проекте просто делил файлы по папкам, в каждую по 10тыс, даже если тысча таких папок будет, то это уже 10млн файлов, структура норм, задержек вроде нет.
Наверное плюс в том что все индексы можно хранить в памяти?
плюсов нет. хранилище, в котором старые файлы циклически перезаписываются для кеша не подходит.
точно так же innodb создает большие файлы, тем самым избавляет от фрагментации файловой системы. И индексы хранит в памяти.
Но mysql вам не пойдет. Вы же слишком круты для такой банальности как mysql :)
может быть смторя какой кэш, можно разбросать по контейнерам в Berkeley DB, это в качестве варианта.
Memcache - есть возможно создание кластера на Memcache :) (это где-то встречал информацию)
плюсов нет. хранилище, в котором старые файлы циклически перезаписываются для кеша не подходит.
точно так же innodb создает большие файлы, тем самым избавляет от фрагментации файловой системы. И индексы хранит в памяти.
Но mysql вам не пойдет. Вы же слишком круты для такой банальности как mysql :)
Ну как я понял с ваших слов, придумывать велосипед не стоит, innodb для этого подходит лучше всего? Единственное не уверен что это полезно базе работать с обычными запросами с кэшем через innodb, надо эти базы раскидывать на разные диски чтоб не возник эффект ступора) Да о чём говорить, я же не знаю как сайт устроен...
Ну как я понял с ваших слов, придумывать велосипед не стоит, innodb для этого подходит лучше всего?
Не так. Просто значение mysql недооценено.
А в свете memcached-интерфейса к innodb и уже широко известного HandlerSocket, так и вообще потенциально очень перспективно.
кстати, у innodb есть недокументированные опции, которые в принципе отключают сброс чего либо на диск до момента нехватки памяти. Хоть и опасно для целостности данных, но для живучего кеша наверное неплохо пойдет.
Да о чём говорить, я же не знаю как сайт устроен...
золотые слова.