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
()
Ответ на: комментарий от vertexua

Ох, извините, мистер Ынтерпрайз, но Java не место в моих проектах в силу её архитектурных особенностей.

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

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

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

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

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

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

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

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

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

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

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

На счёт Redis?

Virtual memory: when your dataset doesn't fit in RAM, you can use VM.

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

VM объявлен deprecated

А, чёрт побери... Redis, по ходу, отпадает.

Chaser_Andrey ★★★★★
() автор топика

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

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

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

Забыл о миллиардах записей. Если бы не столь громадное число - я бы даже и не заморачивался с выбором БД.

Chaser_Andrey ★★★★★
() автор топика
Ответ на: комментарий от 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 ★★★★★
() автор топика
Ответ на: комментарий от vertexua

Обоснуй хотя бы нужность Java для текущей задачи, описанной в шапке топика и прочитай ответ чуть выше.

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