Появилась задача - хранить тексты различной длинны(100 - 5000 символов) . Для бизнес-процесса нужен только текст. Выборки только по точному равенству ключа. Для шардинга думали еще добавить поле "дата" (данные месячной давности запрашиваться будут в сотни раз реже. Кол-во записей до 3ккк.
Приоритеты. Меньший объем потребления диска, озу. На втором месте - скорость чтения. На третьем - запись. Ну и из жизненно необходимого понятное дело что это все дело нужно шардить (не представляю себе 30к Гб на одной машине) и хотябы минимально реплецировать.
Раньше для подобных задач использовали mongodb. Однако функционально в принципе хватит и key-value... В общем выслушаю любые варианты.
Поиск 100% не понадобится, поскольку он и так есть но по обработанным данным. В качестве движка мы на sphinx остановились он экономичней по ресурсам и скорость у него суперская. Но там тоже подумаем над ES, потестим как там щас дела обстоят.
В общем сутки чтения противоречивых ИМХО в интернетах натолкнули на мысль, что в качестве хранилища текстов довольно неплохо выглядить postgresql...
В основном по мотивам - https://habrahabr.ru/post/272735/
нет, ну если nosql вариант со хранением json ? или тоже все плохо?
Мне чертовски лень тестировать все вариацы (ES, Mongo, CouchDB, Mysql+hs(ну да этот вариант скорее всего точно можно отбросить, psql, и тд и тп)...
Потому и конвульсирвую вариантами....
lega: Да... наверное это самое близкое к желаниям...
Только нужно будет написать обертку...
1) Запись. Нужен REST сервис (чтоб дрова для использования отдельно не писать) который будет принимать текст и возвращать id после записи. Запись должна идти в несколько потоков, а значит сервис должен управлять файлами с текстами, для каждого потока свой файл, дабы не было конфликтов. Он же должен рулить чанками. Размер чанка кратен размеру сектора. При запросе на запись сервис должен проверять помещается ли текст в чанк, если нет - создаем новый. И тогда ИД будет такой: ДатаНомерпотокаНомерчанкаПозиция
Опционально можно еще gzip входящих строк прикрутить.
2) Чтение. Тот же REST по ID достает нужный кусок файла..
lega: Я надеюсь завтра у меня появится все-таки время потестить незнакомые и знакомые базы под эту задачу...
Отобрал такие субд - mongo(контрольный образец), psql(json), couchdb, casandra, Hypertable... Может сразу что-то из этого стоит отмести?
psql(json), json тут не нужен, тут blob надо, couchdb вроде как не быстрый, про касандру не знаю как она с чанками, вроде она не для этого,
я хранил чанки в mongodb, сжимал в xs без заголовков, но у меня запросы были диапазонные, в результате я мог выбирать и обрабатывать 16Млн "строк" в сек на одном ядре.
> Размер чанка кратен размеру сектора.
> ДатаНомерпотокаНомерчанкаПозиция
Я думаю чанк тут лишний, тем более погонять под сектора, можно просто: ДатаНомерпотокаПозиция
Но если сравнивать с БД (psql), то скорость записи будет примерно так, psql ~1-5k/sec, в файл ssd 200M/2550=~82k/sec, если быстро сжимать в 4 раза, то ~382k/sec, ну и размер компактней будет.
Средний
