Does this method of storing texts in the form of archives have the right to optimize the speed of work?

Question

Database

Есть идея сделать сайт, где будет много текстов (объявления о работе), сайт будет парсить много источников, по этому будет оч оч много текстового контента. БД будет иметь миллионы записей.
Если хранить эти тексты с описанием вакансий в БД то она очень быстро разрастается и БД начинает подтормаживать....
Есть вариант решения: Хранить в БД только название вакансии и параметры для поиска, а описание хранить в ZIP архивах.
Принцип работы будет такой:
При запросе к информационным страницам (списки) будет браться информация из БД, а при переходе к полному тексту вакансии - уже из файла.
Использовать собираюсь ВПС от ЦифровогоОблака на ССД дисках не очень дорогой (20 уе в мес, 2GB memory, 2 CPU, 40GB SSD)
Возник ряд вопросов:
1) Имеет ли смысл хранить текстовую информацию в файлах, ведь, по идее, это ССД и читаться из файла будет тоже быстро?
2) Имеет ли смысл эти файлы архивировать, ведь файлы не большие и архивированный файл все равно будет занимать примерно столько же места?
3) Имеет ли смысл разбивать архивы по папкам/подпапкам - чтобы не было очень много файлов в одной папке и не тормозило (помню по теории *никсовых систем что нельзя много миллионов файлов в одной папке хранить)?
4) Вообще такое решение имеет право на жизнь? Отговорите меня от него...
5)Стоит ли сжимать файлы или хранить как есть?
Я не Яндекс и кластеров под сайт с посещаемостью в 200 человек я покупать не буду и как сделать это ПРАВИЛЬНО я знаю))) Но хочется сэкономить...

Answer 1

Does it make sense to store textual information in files, because, in theory, this is an SSD and it will also be read from a file quickly?

It doesn't make sense in your case. Read at your leisure what inodes are and what happens when they run out.
Doesn't have. If you need to display, for example, 10 vacancies on the page, and one of them is currently being edited by another user, you will still have to cover yourself with read-write locks, and also spend a lot of time unzipping the data each time. This is called "pissing off resources".
For file storage, this approach has the right to life.
Для вашей задачи - со всей силы нет. Полнотекстовый поиск вы не обеспечите, для организации контроля конкурентного доступа вам придется городить свои костыли, архивация и деархивация будут занимать много времени

Answer 2

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

Answer 3

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

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

In general, keeping the job title separate from the detailed job description is the right approach. And compressing text data is also correct. It's just not worth storing descriptions in ZIP files for reasons described by index0h . Correctly store data in the DBMS. And the text data itself can be compressed by any compression algorithms before entering. I also want to be clear that ZIP is a file container that can use various compression algorithms, from Shrunk and Deflate to the likes of PPMd.
In InnoDB MySQL 5.7, compression can be applied transparently using the directive COMPRESSION:
Since vacancies are usually repeated from month to month, from one message board to another, there is likely to be multiple duplication of the same vacancies. In this case, you can apply an optimization technique called "data deduplication".
To do this, you can calculate the hash sum with cryptographic hash functions such as SHA-1. The same job descriptions will have the same hash value, allowing only one copy of the description to be stored. In this case, the data will grow much more slowly than without this technique.
Relationships can be stored like this:
job_vacancies(id, ...) <-> relations(source_id, packed_contents_id) <-> packed_contents(id, hash_sum, blob)
It hardly makes sense to do the same with job titles.