Имеет ли право такой способ хранения текстов в виде архивов для оптимизации скорости работы?

Question

[VisualIdeas]

Есть идея сделать сайт, где будет много текстов (объявления о работе), сайт будет парсить много источников, по этому будет оч оч много текстового контента. БД будет иметь миллионы записей.
Если хранить эти тексты с описанием вакансий в БД то она очень быстро разрастается и БД начинает подтормаживать....
Есть вариант решения: Хранить в БД только название вакансии и параметры для поиска, а описание хранить в ZIP архивах.

Принцип работы будет такой:
При запросе к информационным страницам (списки) будет браться информация из БД, а при переходе к полному тексту вакансии - уже из файла.

Использовать собираюсь ВПС от ЦифровогоОблака на ССД дисках не очень дорогой (20 уе в мес, 2GB memory, 2 CPU, 40GB SSD)

Возник ряд вопросов:
1) Имеет ли смысл хранить текстовую информацию в файлах, ведь, по идее, это ССД и читаться из файла будет тоже быстро?
2) Имеет ли смысл эти файлы архивировать, ведь файлы не большие и архивированный файл все равно будет занимать примерно столько же места?
3) Имеет ли смысл разбивать архивы по папкам/подпапкам - чтобы не было очень много файлов в одной папке и не тормозило (помню по теории *никсовых систем что нельзя много миллионов файлов в одной папке хранить)?
4) Вообще такое решение имеет право на жизнь? Отговорите меня от него...
5)Стоит ли сжимать файлы или хранить как есть?

Я не Яндекс и кластеров под сайт с посещаемостью в 200 человек я покупать не буду и как сделать это ПРАВИЛЬНО я знаю))) Но хочется сэкономить...

Comments

[Wexter]

если уж так хотите сэкономить то тяните тексты с источника напрямую, без сохранения у себя

[VisualIdeas]

Wexter: ТОгда скорость будет вообще никакая, также источник может удалить вакансию

[Юрий]

VisualIdeas: если удалит то скорее всего не актуальная

[VisualIdeas]

SEO - важна отметка НЕ АКТУАЛЬНО но страница должна существовать

Answer 1

[index0h]

Имеет ли смысл хранить текстовую информацию в файлах, ведь, по идее, это ССД и читаться из файла будет тоже быстро?

Смысла в вашем случае нет. Почитайте на досуге, что такое inode и что происходит, когда они заканчиваются.

Имеет ли смысл эти файлы архивировать, ведь фалы не большие и архивированный файл всеравно будет занимать примерно столько же места?

Не имеет. Если на странице надо отобразить например 10 вакансий, а одну из них в данный момент редактирует другой пользователь вам придется еще обмазаться блокировками чтения записи, так же потратить кучу времени на разархивацию данных каждый раз. Это называется "просрать ресурсы".

Имеет ли смысл разбивать архивы по папкам/подпапкам - чтобы не было очень много файлов в одной папке и не тормозило (помню по теории *никсовых систем что нельзя много миллионов файлов в одной папке хранить)?

Для хранения файлов подобный подход имеет право на жизнь.

Вообще такое решение имеет право на жизнь?

Для вашей задачи - со всей силы нет. Полнотекстовый поиск вы не обеспечите, для организации контроля конкурентного доступа вам придется городить свои костыли, архивация и деархивация будут занимать много времени

Answer 2

[Philipp]

Имеет смысл использовать базу данных, умеющую их сжимать. Например MongoDB сжимает данные примерно в 2 раза от их размера на диске при использовании WiredTiger и полнотекстового индекса. Не знаю, как с сжатием дела в MySQL или PostgresQL. Наверняка что-нибудь уже есть.
Для сайтов о работе поиск вакансий критически важный функционал, от работы которого полностью зависит успешность вашего проекта.

Ответы на вопросы

1. Не имеет. Работа с файлам отнимет большую часть времени на разработку проекта, особенно операции редактирования, обновления информации.
   
2. Архивировать нет смысла, исключение могут лишь составить разного рода прикрепленные документы в формате doc, xls и т.д., которые хорошо сжимаются и которые технически проще отдавать с диска напрямую. Можно архивировать в gzip в виде сгенерированной странички. Тогда nginx будет ее напрямую клиенту отдавать. Сэкономите на месте и времени CPU.
   
3. Имеет смысл разбивать на папки, если у вас там будут миллионы файлов в папки. Просто из банального удобства навигации. В остальном вы ограничены количеством inodes.
   
4. Решение не самое красивое, но имеет право на жизнь. Я бы так делать не стал.
   
5. Сжимать файлы не стоит. Используйте MongoDB, она умеет все сжимать по умолчанию. В ней есть полнотекстовые индексы. Если надумаете дальше развивать проект, то его будет легко смаштабировать.
   

Я не занимаюсь рекламой MongoDB. Я использую ее уже на протяжении 3-х лет в продакшене под серьезной нагрузкой и знаю ее сильные стороны.
По поводу базы - если очень хочется, можете архивировать и хранить архивированные файлы прямо в том же MySQL. Просто когда будете вытаскивать данные при поиске, не делайте SELECT * Выбирайте только требуемые поля. И про индексы не забудьте.

Comments

[VisualIdeas]

Я сейчас раздумываю именно о полном тексте вакансии, не о функционале поиска

[Philipp]

Так вы сожжете процессор распаковывая и запаковывая текст. Ваш контейнер будет тормозить на распаковке. Например краулер гугла с яндексом зайдут на ваш сайт и сожрут все время контейнера, пока тот будет расжимать и отдавать данные на клиент.

[VisualIdeas]

Philipp: Ну можно не сжимать а просто файлами хранить

Answer 3

[sim3x]

1) Имеет ли смысл хранить текстовую информацию в файлах, ведь, по идее, это ССД и читаться из файла будет тоже быстро?

да, стразу в гзипе с nginx.org/en/docs/http/ngx_http_gzip_static_module.html

2) Имеет ли смысл эти файлы архивировать, ведь фалы не большие и архивированный файл всеравно будет занимать примерно столько же места?

да

3) Имеет ли смысл разбивать архивы по папкам/подпапкам - чтобы не было очень много файлов в одной папке и не тормозило (помню по теории *никсовых систем что нельзя много миллионов файлов в одной папке хранить)?

нет

5)Стоит ли сжимать файлы или хранить как есть?

просто для отдачи - сжимать, для поиска и обработки - не сжимать и хранить в бд

быстро разрастается и БД начинает подтормаживать

мда

Answer 4

[Максим]

1) Имеет
2) Не архивировать
3) Это на вкус и цвет
4) можно было бы "запаковать2 часть информации, например табл1:
01 - повар
02 - сторож
табл2:
01 - Москва
02 - Питер
и т.д.
сам файл именовать: 01-01.txt или 02-01.txt
При поиске можно уже "генерировать имя файла".
5) не стоит хранить в zip
6) чтобы боты не порушили сайт использовать в robots.txt директиву Crawl-delay

Answer 5

[d'Ivan]

Есть вариант решения: Хранить в БД только название вакансии и параметры для поиска, а описание хранить в ZIP архивах.

В целом, хранение названия вакансии отдельно от подробного описания вакансии - правильный подход. И сжимать текстовые данные - тоже правильно. Вот только хранить описания в файлах ZIP не стоит по причинам, описанным index0h . Правильно хранить данные в СУБД. А сами текстовые данные можно сжимать любыми алгоритмами сжатия перед занесением. Также хочу прояснить, что ZIP - это контейнер файлов, в котором могут использоваться различные алгоритмы сжатия, от Shrunk и Deflate до таких как PPMd.

В InnoDB СУБД MySQL 5.7 сжатие может применяться прозрачно при помощи директивы COMPRESSION:
CREATE TABLE t1 (c1 INT) COMPRESSION="zlib";

Поскольку вакансии обычно повторяются из месяца в месяц, от одной доски сообщений к другой, то скорее всего имеет место множественное дублирование одних и тех же вакансий. В таком случае можно применить технику оптимизации под названием "дедупликация данных".
Для этого можно вычислять хеш-сумму криптографическими хеш-функциями, такими как SHA-1. Одни и те же описания вакансий будут иметь ту же хеш-сумму, что позволит хранить лишь одну копию описания. В таком случае данные буду разрастаться гораздо медленнее, чем без этой техники.

Связи можно хранить так:
job_vacancies(id, ...) <-> relations(source_id, packed_contents_id) <-> packed_contents(id, hash_sum, blob)

С названиями вакансий вряд ли имеет смысл делать аналогично.