LINUX.ORG.RU

В какой БД можно хранить и обрабатывать миллиарды записей без большого оверхеда на объем? BerkeleyDB? Что-то из NoSQL?


0

2

Доброй ночи! Ищу для скромного justforfun'овского проекта относительно быструю БД, в которой можно хранить и обрабатывать миллиарды записей. Пока что остановился на BerkeleyDB.

Записи представляют собой небольшую текстовою строку (~10-100 символов) в ASCII или Latin1 и несколько флагов/значений, которые и должны быть вторичными ключами. Каждая строка уникальна, если это имеет значение.

Что нужно:

  • Быстрая выборка по основному и вторичному ключам (вторичных ключей может быть несколько), в том числе множество значений.
  • Минимальный оверхед на хранения каждой записи.
  • Очень желательна прозрачная компрессия, например, алгоритмом lzo, так как данные текстовые, и очень много почти однотипных (различие от одного до нескольких символов). Или это некошерно?
  • Быстрый апдейт записей, в том числе значений вторичных ключей.
  • Весьма желательная быстрая вставка порядка сотен тысяч записей (При подобных тестах производительность MySQL makes me cry).
  • Очень желательно наличие блокировок
  • Очень желательно наличие транзакций

Что не нужно/не обязательно:

  • Сетевой доступ.
  • Одновременный множественный доступ на запись/чтение.
  • Разграничение прав.
  • Отдельный сервер (в смысле демон) БД. Меня устроит и встраиваемая.

Что не устраивает в BerkeleyDB:

  • Так как для каждого вторичного ключа нужна «secondary database», то мне кажется, там будет нехилый оверхед на каждую запись. В других БД дела обстоят ещё хуже?
  • Ужасающие тормоза вторичных бд в Berkeley DB - и это при том, что речь идёт всего лишь о миллионах записей. Лично сам пока не тестил.

Я так понимаю, с такими запросами даже не следует смотреть в сторону SQL-based БД, т.е., остаются только NoSQL-решения.

Ещё видел штуки вроде:

  • MemcacheDB - использует BDB в качестве бэкэнда, профит от самой MemcacheDB неочевиден.
  • Apache Cassandra/Apache Hadoop - не подходит, ибо Java.
  • MongoDB - документо-ориентированная БД, разве подойдёт под мои задачи?

Жду совето, ЛОР!

Статья об ужасающих тормозай bdb - 2008 года. Попробуйте проверить на похожих данных сейчас, может быть работа с такими индексами ускорена.

Но если проблема всё равно есть, то её можно обойти, добавив в ключ вторичной БД ключ первичной. Насколько я помню, в bdb можно искать запись, ближайшую снизу или сверху к ключу. Кстати, именно поэтому в статье можно было бы обойтись без вторичной БД вообще.

Sorcerer ★★★★★ ()

Очень желательна прозрачная компрессия, например, алгоритмом lzo, так как данные текстовые, и очень много почти однотипных (различие от одного до нескольких символов). Или это некошерно?

читал, что такое есть в DB/2 CE 9.7

Karapuz ★★★★★ ()

postgresql + партицирование данных изкаробки
200-300 гигов данных - не проблема.

anonymous ()

Ищу для скромного justforfun'овского проекта относительно быструю БД, в которой можно хранить и обрабатывать миллиарды записей.

Хрена себе just4fun'ановский проект.

MS SQL же. =) А если серьезно, то покопай в сторону postgresql.

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

Во-первых он пишет, что используется флаг DUP, во-вторых ни слова нет о данных и о настройках базы. По своему опыту могу сказать, что berkeley на миллионах записей работает отлично. Миллиард сомневаюсь, что осилит.

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

По-моему, в статье достаточно информации, о данных в том числе. Топикстартер тоже DUP с миллионами дубликатов хочет.

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

Глянь Redis.

Редис нормально работает с данными сильно больше чем объем оперативки? VM объявлен deprecated, они обещают его когда-нибудь вернуть, но в 2.6 его уже не будет.

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

Была подобная же задача, решилось все написанием своего велосипеда.

shutty ()

NoSQL нужно использовать тогда, когда доказана невозможность использовать SQL. Пока что объем твоих данных (~100ГБ) как-то не взывает к NoSQL.

Очень желательна прозрачная компрессия, например, алгоритмом lzo, так как данные текстовые, и очень много почти однотипных (различие от одного до нескольких символов). Или это некошерно?

10 символов сжимать бессмысленно.

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

Хрена себе just4fun'ановский проект

С ботнета, наверно, данные собирает. ;)

Reaper ★★ ()

Tokyo Cabinet

Для некоторых кейсов одно из наилучших решений

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

tailgunner> NoSQL нужно использовать тогда, когда доказана невозможность использовать SQL. Пока что объем твоих данных (~100ГБ) как-то не взывает к NoSQL.

Chaser_Andrey> Весьма желательная быстрая вставка порядка сотен тысяч записей (При подобных тестах производительность MySQL makes me cry).

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

+ не забываем при заливке больших объёмов дропать индексы, а после - создавать взад (если позволяет тип нагрузки)

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

Да уж, наверняка следует сделать тесты для постгреса

Ты только autocommit отключить не забудь %)

Хотя всё-же ожидаю плохие результаты в этом конкретном случае.

Что ж, значит, SQL-серверы для твоей задачи не подходят.

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

За линк спасибо, упустил с виду.

Redis заинтересовал, надо бы детальней с ним разобраться.

Chaser_Andrey ★★★★★ ()

Что нужно:
* Весьма желательная быстрая вставка порядка сотен тысяч записей (При подобных тестах производительность MySQL makes me cry).
* Очень желательно наличие блокировок
* Очень желательно наличие транзакций
Что не нужно/не обязательно:
* Сетевой доступ
* Одновременный множественный доступ на запись/чтение.
* Отдельный сервер (в смысле демон) БД. Меня устроит и встраиваемая.

Ты описываешь SQLite

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

Память!!

Подумаешь, всего-то 100 гигов. Есть SMP-кластеры на 256

annulen ★★★★★ ()

# Весьма желательная быстрая вставка порядка сотен тысяч записей (При подобных тестах производительность MySQL makes me cry).

Storage engine какой? InnoDB?

gods-little-toy ★★★ ()
Ответ на: комментарий от gods-little-toy

Storage engine какой? InnoDB?

Кстати там и компрессия имеется в последних версиях.

gods-little-toy ★★★ ()

Что нужно:

...

* Очень желательно наличие блокировок

* Очень желательно наличие транзакций

Что не нужно/не обязательно:

* Одновременный множественный доступ на запись/чтение.

Зачем тебе блокировки, если множественный доступ не нужен?

gods-little-toy ★★★ ()

Ужасающие тормоза вторичных бд в Berkeley DB -

по ссылке пишут:

В случае, если количество ваших сотрудников стремится к 2 — 3 миллионам, то готовтесь, что обращение к первичной БД начнет на столько “тормозить”, что почти остановит работу системы.

В случае, если количество ваших сотрудников стремится к 2 — 3 миллионам,

админы FoxConn чтоле?

gods-little-toy ★★★ ()
Ответ на: комментарий от Chaser_Andrey

вам таки 2^64 мало?

погоняйте тесты. по вашему описанию подходит. может тесты подтвердят

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

Наоборот, SQL нужно использовать тогда, когда доказана невозможность использовать NoSQL. Иначе при росте нагрузок будет страшный геморрой с переписыванием всего софта под nosql.

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

SQL нужно использовать тогда, когда доказана невозможность использовать NoSQL

«You're not Facebook» (с)

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

в силу её архитектурных особенностей

архичего? олсо, гуглу подходит, а...

Однако, JGit работает вполне нормально; достаточно быстро для того, чтобы мы использовали его как как сервер git внутри Google. http://habrahabr.ru/blogs/programming/136210/

а Chaser_Andrey не подходит, как так?

Karapuz ★★★★★ ()

Tokyo Cabinet/Kyoto Cabinet смотрели?

Kyoto Cabinet runs very fast. For example, elapsed time to store one million records is 0.9 seconds for hash database, and 1.1 seconds for B+ tree database. Moreover, the size of database is very small. For example, overhead for a record is 16 bytes for hash database, and 4 bytes for B+ tree database. Furthermore, scalability of Kyoto Cabinet is great. The database size can be up to 8EB (9.22e18 bytes).

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

Автор сам рекомендует Kyoto. Выше уже мне предлагали. Что ж, посмотрел. Выглядит впечатляющее. К тому же:

Kyoto Cabinet is written in the C++ language

API of C++, C, Java, Python, Ruby, Perl and Lua

GNU General Public License

Просто замечательно! Обязательно проведу тесты. Может, это действительно то, что мне нужно.

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

Хотя всё-же ожидаю плохие результаты в этом конкретном случае.

Ну-ну. Ты только вначале постгрес настрой хоть как-то, дефолтные настройки никуда не годятся. Стоимость операций - самое важное.

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

Школота - это состояние мозга, а не возраст.

А студентота отличается от школоты лишь иллюзией, что ну теперь-то они точно что-то знают.

Pavval ★★★★★ ()

Если данные структурированы, любая нормальная СУБД.

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

По ссылке я прочёл кучу объяснений, почему Java не может быть такой быстрой, как C/C++, и какие костыли приходится городить, чтобы выиграть хоть какие-то проценты производительности.

1. Не вижу смысла в Java, если есть отличные решения на C/C++.

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

3. Не думаю, что решения на Java смогут соревноваться с тем же Kyoto Cabinet (Kyoto Cabinet runs very fast. For example, elapsed time to store one million records is 0.9 seconds for hash database, and 1.1 seconds for B+ tree database. Moreover, the size of database is very small). В этом конкретном случае скорость работы и размер БД для меня на первом месте.

4. Случай с гитом и мой случай весьма отличаются. Разве в гите идёт речь о миллионах записей в секунду и миллиардах общих записей?

Да и вообще, чуваки написали свой гит на Java (хотя есть прекрасно работающее решение на сях), получили более толстое и медленное решение, потратили кучу человекочасов на самый что ни на есть велосипед. Вопрос - а в чём профит?

Chaser_Andrey ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.