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 - документо-ориентированная БД, разве подойдёт под мои задачи?

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

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

Быстрая по сравнению с чем? Может ли оно соревноваться по быстроте и компактности хранения данных с упоминаемыми выше решениями?

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

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

Им нужна была библиотека на Яве, реализующая Git, и они ее написали (Git на Си написан довольно говенно и для использования в качестве библиотеки не подходит).

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

Когда данных очень много, быстрее кассандры вроде ничего не создавали. Гугл в помощь (хм, но возможно у самого гугла есть что-то получше). Hadoop выиграл конкурс по обработке какого-то большого объема данных, не его основе сработало быстрее всего.

Cabinet насколько помнится проприетарен и когда данных становится слишком много, то на многих форумах описывают как мигрировали на кассандру

vertexua ★★★★★
()

westtrd, JFreeM: у Tokyo/Kyoto Cabinet нет нормальной поддержки вторичных индексов с атомарными операциями, что очень печально.

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

Для меня скорость разработки стоит на втором плане, на первом плане - конечная скорость приложения и оптимизация потребления памяти

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

купить железно проще и намного дешевле, чем найти дорого профессионала для поддержки твоего supa-bupa-high-tech решения с гениальными ходами.

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