Какую базу NOSQL использовать для хранения миллиардов записей?

Question

[wanomgn]

Уважаемые коллеги
Есть нужда хранить кучу (точно десятки миллиардов) данных вида:
1 столбец: хэш 16 цифр 2 столбец данные: текст 254 символа
для примера
5946586474531598 тесттестстет
1193554650756954 ещетестещетестещетест

логично предположить что лучше всего это будет лежать в NOSQL базе..
все данные в память не войдут никоим образом - поэтому "мемори-онли" базы точно не подойдут.
документ-ориентированные базы тоже вроде ни к чему тут..
доступ осуществляется к любым данным в базе.
вопрос: в какой конкретно базе хранить? есть ли варианты базы с компрессией? хочется не особо замороченный вариант с распаралеливанием на несколько компов..

Comments

[lega]

> текст 254 символа
Всегда 254 или это максимум?

> доступ осуществляется к любым данным в базе.
Какой доступ? Поиск текста по хешу? Полнотекстовый?

> хэш 16 цифр
это хеш от текущего текста или они не связаны?

Как часто происходит добавление/обновление и чтение (нагрузка)?

[wanomgn]

lega: от 1 до 254. выборки по хэшу. хэш расчитывается внешней программой и в базу заносится просто как цифра. естественно у одинакового текста одинаковый хэш (хэши в базе уникальны (про коллизии знаю - они не важны))

[wanomgn]

Анатолий K: redis?? он же вроде как в оперативе живет... как в нем миллиарды записей то хранить?

Answer 1

[Максим Кузнецов]

Мы используем mongodb

Comments

[wanomgn]

Не является ли излишним (в плане производительности) то что mongodb документо-ориентированное хранилище?

[Максим Кузнецов]

Смотря что понимать под документами. Мы храним события, происходящие в большой распределённой системе. Нагрузка примерно та же, что и у Вас. Миллиарды записей в сутки. Структура похожа: guid, штамп времени, данные в формате bson. Записи идут от десятков тысяч устройств квазинепрерывно: паузы могут быть из-за проблем со связью (местами есть только gprs), при этом при восстановлении связи данные погружаются.

Answer 2

[sim3x]

монгодб, пот, кровь, сопли, овертайм. (с)ya.disk

доступ осуществляется к любым данным в базе

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

вопрос: в какой конкретно базе хранить?

ответ в любой, даже в sqlite

есть ли варианты базы с компрессией?

есть leveldb

хочется не особо замороченный вариант с распаралеливанием на несколько компов..

тут вообще непонятно о чем речь, то ли о шардинге, то ли о репликации

Comments

[wanomgn]

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

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

тут вообще непонятно о чем речь, то ли о шардинге, то ли о репликации

о шардинге
естественно важна скорость выборки по случайному(существующему в базе) хэшу.

[sim3x]

wanomgn: частота селект/апдейт/делете/инсерт?

[wanomgn]

сейчас на mysql на tokudb load data in file ignore инсертит около 20-40т строк в секунду. этого хватает. удалений нет. а вот селекты перестали "удовлетворять"

[sim3x]

wanomgn: те апдейтов нет?

[wanomgn]

sim3x: нет

[sim3x]

wanomgn: похоже на лог-лайк схему использования, для которой все ехидно советовали монгу

Но без тестов, приближенны к боевым, я б не выбирал.
Мускул, постгрес, монга, и немного екзотики it-io.com/article/10192299481740042709.html