LINUX.ORG.RU
Форум — Development  

Полухоливарный вопрос о выборе СУБД и организации системы поиска среди 100 млн текстовых сообщений.


0

1

Давайте попробуем выбрать аппаратно-программное решение.

В день добавляется новыйх 250 тыс. сообщений.
Средний размер сообщения - 200 байт.
В мегабайтах - 60.
Это наиболее суровая ожидаемая нагрузка.
Если предположить, что 70% сообщений добавляется в период 9-18 часов (70% = 175000 штук), получим 324 сообщения в минуту = ~5 сообщений в секунду.

Но скорость не важна, т.к. добавляться в базу они должны пачками, штук по 100 сразу и супербыстрое добавление не важно.

Через месяц в базе будет 7750000 (7.7 млн) сообщений, 1.8 гигов сырых данных.

Через год - 93 млн. сообщений, 22.2 гига данных.

Вопросы хардварно-софтварные:
1. Полнотекстовый поиск в 93 млн сообщениях средней длины 200 байт.
2. Аппаратное обеспечение для предложенной платформы.

Обычная задача многокритериальной оптимизации: чем дешевле, тем лучше и чем быстрее поиск, тем лучше. Поиск фраз состоящих из 1, 2, 3 слов должен идти, например, за секунду. Сортировка по свежести сообщений, по категории (С++/психология/путешествия).

Какая это должна быть DMBS? Какая архитектура (один сервер или несколько дешёвых компов на ATOM, партиционирование, репликация, шардинг). Как лучше всего организовать таблицу с 93 млн сообщениями, при условии того, что наибольшая нагрузка на неё идёт в режиме чтения последних 250000 сообщений (последние сутки), но хотелось бы добираться до сообщений за весь год (возможно, медленнее). Это называется репликация, как я понимаю - по ночам скидываем все данные на слейв-серверы, на мастер-сервере оставляем только последние несколько суток. Какая для этого поддержка есть в MySQL, Postgres? Как будет выглядеть операция «переместить пол-таблицы с наиболее старыми записями на другой сервер» на уровне языка SQL и процедур конкретных систем DMBS?

Вопросов бесконечная куча, но основные заданы. Не занимаюсь DBA, раньше разрабатывал in-memory NoSQL-решение на большом толстом сервере, но здесь бюджет не тот, чтобы покупать профессиональное оборудование. Бюджет на эти эксперименты позволяет поиметь максимум несколько недорогих обычных компов с толстыми сигейтами.

← Работа с SCREEN
Интерпретатор/компилятор Scheme →

Cassandra, MongoDB. Обоих лучше потестить. Поставь, загони туда 10 ГБ даных и делай выводы

vertexua ★★★★★
()

Какая это должна быть DMBS?

PostgreSQL, если рассматривать решения на базе СПО. Если не на базе СПО, то всё равно pgsql ибо большего здесь не нужно.

Какая архитектура (один сервер или несколько дешёвых компов на ATOM...)

Зависит от многих деталей, начать лучше с одной железки с возможностью наращивания ресурсов.

Как лучше всего организовать таблицу с 93 млн сообщениями, при условии того, что наибольшая нагрузка на неё идёт в режиме чтения последних 250000 сообщений (последние сутки), но хотелось бы добираться до сообщений за весь год (возможно, медленнее).

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

по ночам скидываем все данные на слейв-серверы, на мастер-сервере оставляем только последние несколько суток.

И то, это при условии что действительно вылезаете за пределы одной железки или условия эксплуатации к этому поддалкивают. Например, записи последних дней используются в ОLTP приложении, а поиск и сортировки в OLAP или DWH.

Как будет выглядеть операция «переместить пол-таблицы с наиболее старыми записями на другой сервер» на уровне языка SQL и процедур конкретных систем DMBS?

Никак, нужно делать руками. Есть готовые и «полуготовые» системы, вероятно для вашей задачи лучше всего подойдёт londiste. С этим моментом придётся немного потрахаться.

Теперь о самом поиске. Есть, конечно, FTS для СУБД, но для ваших условий навряд ли получится их эффективно использовать. Смотреть нужно на внешние индексаторы типа sphinx.

mashina ★★★★★
()
Ответ на: комментарий от mashina

sphinx.

Он уже научился инкрементальному индексированию? Давно не следил.

baverman ★★★
()

система пишется на жабаскрипте. Работает на клиенте. Основная Идея - переводим гугол-транслейтом на китайский и храним все в твитыре. или в фейсбуки.

*.js-ку, которая это все делает, раздаем людям с амазона. Всё.

gods-little-toy ★★★
()

Советую взглянуть на elasticsearch. Это поисковый движок на основе Lucene, который поддерживает шардинг, репликацию, инкрементальное индексирование и предоставляет удобный API.

dmitry_vk ★★★
()

а может проще будет написать программу на Си ?
если сообщение одного размера - 256 байт скажем
хранение в файлах - один файл один день

+ продумать систему хэширования - для поиска по словам

ae1234 ★★
()
Ответ на: комментарий от ae1234

а может проще будет написать программу на Си ?

В общем, поддерживаю :)

Надо придумать некую абстрактную структуру данных в самом простом виде. Потом думать, как реализовать. Например, отдельно список слов. К каждому слову привязан список указателей на их вхождения в сообщения. В принципе, просто хранить и добавлять, и даже переиндексировать при необходимости.

Deleted
()
Ответ на: комментарий от Deleted

да я просто о том что может как проще сделать
бд = файлы
и такое же хранение хешей/индексов

никаких проблем ни с хранением - ни с распредлеением + ...
элементарное добавление нового - и поиск

ae1234 ★★
()
Ответ на: комментарий от ae1234

И реализовать можно хоть на микроконтроллере.

Deleted
()
Ответ на: комментарий от ae1234

> если сообщение одного размера - 256 байт скажем

хранение в файлах - один файл один день
+ продумать систему хэширования - для поиска по словам

not-sure-if-trolling-or-just-stupid.png

vladimir-vg ★★
()
Ответ на: комментарий от mashina

>>Какая это должна быть DMBS?

PostgreSQL, если рассматривать решения на базе СПО.


В данном случае я вообще не вижу смысла в реляционной БД. Почему бы ТСу не посмотреть в сторону CouchDB, MongoDB, Cassandra - в общем, NoSQL решений, ведь схема данных примитивна, а упор нужно делать как раз-таки на сильные стороны NoSQL - масштабирование и скорость.

Corey ★
()
Ответ на: комментарий от vladimir-vg

Who need you to be sure of something? You are free to be not sure of anything.

kiverattes ★☆
() автор топика
Ответ на: комментарий от Corey

>сильные стороны NoSQL - масштабирование и скорость.

Скорость?!!!... Вы серьёзно? Может лучше глянуть что-то вроде BerkeleyDB?

yyk ★★★★★
()
Ответ на: комментарий от kiverattes

формально - да, но я уже привык под этим термином подразумевать Cassandra, MongoDB и прочих. А key-value хранилища, это как ассемблер среди языков программирования :)

yyk ★★★★★
()

Postgresql - noway. Предлагать может только тот, кто кроме оного не пробовал ничего.

Начните хоть с чего-нибудь. Все равно придется переписывать.

Kpoxman ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Работа с SCREEN
Development
Интерпретатор/компилятор Scheme →