LINUX.ORG.RU

Посоветуйте column-based СУБД для быстрого добавления 1 млн записей в минуту и запроса их оттуда редкого, но быстрого.

 


0

2

Есть запись (entry). Она делится на условные Key и Value. Key состоит из 5 строковых полей и пары INT-овых, по каждому из которых хотелось бы выбирать Value, на которое показывает этот составной Key. Value состоит из 5 int-значений и хотелось бы выбирать всегда какое-то одно из них. Т.е. Value — это вектор INT-ов. Т.е. это база для аналитики. Т.е. быстрее всего будет column-based.

Обозначим все поля Key как Key:0, Key:1 и т.п. Все поля Value как Value:0, Value:1, Value:2 и т.п. Тогда:

Варианты запросов, которые должны летать:

вот Key:1, дайте последовательность всех Value:2 за последний день

нет Key («любое значение»), дайте последовательность всех Value:2 за последний день

вот Key:0 И Key:1, дайте последовательность Value:2 за последний день

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

Что стоит посмотреть? Yandex ClickHouse?

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

iSage ★★★★
()

cassandra полностью подходит. Главное правильно индексы проставить. Жмет отлично данные по столбцам.

TOXA ★★
()

требования весьма противоречивые. Быстрая запись одновременно с быстрыми условными запросами не бывает, тем более не бывает такое богатство со сколь-нибудь малым потреблением ресурсов. Можно писать в одну базу, какойнить no-sql без ничего или вообще в файл, потом периодически сливать оттудова большие пачки данных уже в чего-нибудь вменяемое со столбцами и многоколоночными индексами и, возможно, партицированием.

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

Быстрая запись с быстрым чтением бывает: контора Tokutek вон коммерциализировала buffered B-Tree, описанные Lars Arge (имя чувака).

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

SQLite для key-value storage? Тормозить будет довольно сильно.

ТС-у нужно что-то типа memcached

скорее всего ТС`у этого будет заглаза. А вообще точно так.

ТС точно не специализируется в highload, цифры взяты с потолка, и вопросы такого уровня (10^7/sec) не решаются на ЛОР, тут ему таакого насоветуют :-) Так что SQLite дабы ножку не сломать на первых этапах..

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

Где ты прочитал про 10^7 / sec? Цифры тут упоминались максимум 10^6, а вместо сек упоминалась минута.

Я прекрасно понимаю что тут насоветуют, но мне никто не запрещал посылать любые совету нах.

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

мало ли что там какая контора нарисовала (тем более особо не заметно открытия грааля святого, всем как-то пофиг на их tokudb). Суть не в конкретном продукте, а в том, что большинство методов ускорения выборок данных по неким условиям (индексы и прочее вот это вот все с деревьями, фракталами и чертями рогатыми) замедляет сих данных запись относительно случая их отсутствия.

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

индексЫ? мб я отстал от жизни, и ковырял ее довольно давно, но поиметь в кассандре несколько индексов по воспоминаниям было не очень-то можно.

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

Замедляет конечно. Но речь не о том, чтобы получить максимальную скорость чтения, когда голова диска читает сектора последовательно и никуда не перемещается :)

hlamotron
() автор топика

кстати

вот Key:1, дайте последовательность всех Value:2 за последний день

какое время выдачи результата по такому запросу будет признано приемлемым? Даже если не фильтровать по дате, а иметь только значения одного дня, это, на минуточку, 1.44e+9 записей, из которых нужно выгрести нужные по значению одного из ключей.

arkhnchul ★★★
()

<sarcasm> SybaseIQ <sarcasm/>

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

SQLite дабы ножку не сломать на первых этапах..

10**6 записей в минуту многовато для SQLite. Может, конечно, ТС слегка перестраховался, данных будет меньше.

Допустим, если у него сырая запись (ключ+значение) около 500 байт, в день получается 720Г. Это без всяких дополнительных расходов на индексы и прочее. Даже если запись по 100 байт, получается почти 150Г в день.

SQLite для такого лучше рассматривать где-то в конце списка. Где-то за остальными РСУБД общего назначения.

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

Обычно делают что-то вроде map-reduce. Фильтруют и агрегируют в небольшую таблицу (в key-value хранилище или даже в СУБД) то что нужно получить быстро. То, что нужно редко нет смысла предпросчитывать. Можно по запросу пересканировать исторические данные для редких и необычных запросов, пользователь подождет

Deleted
()
Ответ на: комментарий от exception13

Cassandra
ЕМНИП добавление там самая дорогая операция.

Наоборот. Писать новые записи дёшево и быстро, читать - чуть дольше.

migesok
()
Ответ на: комментарий от TOXA

о, я действительно отстал от жизни) благодарствую

хоты там вроде индексы на строгое равенство, все равно лучше, чем ничего.

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