приветствую!

подстакажите пожалуйста, какой движок способен справится с такой задачей:
одна таблица.
перманентное количество записей в базе ~8 миллиардов.
одна запись: string, datetime, blob (1024b). возможно добавится еще пара полей.
~85 миллионов инсертов и делитов в день.

необходимо осуществить поиск по первому и второму полю.

желаемый фидбэк <= 1cек

железо, предроложительно, ibm blade + какой-то дисковый массив (пока ничего не известно).

что можете порекомендовать ?

спасибо!

казалось что задача сложная, но видимо я безповоротно отстал от мэйнстрима :)

всем спасибо!

SergSuper,

подробнее можно ?

SergSuper,

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

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

скверно то, что сдача через месяц а на данный момент результат NULL.

Имхо, у грамотно разработанной структуры каталогов и системы именования файлов очень неплохие шансы на успех при очень скромных накладных расходах. Правда, могут быть потеряны СУБД-специфичные плюсы, такие как транзакции и т.п.

подобное решение пришло в голову одним из первых.
чуть подробнее. первый ключ стринг это номер телефона.
количество абонентов (уникальных ключей)порядка 5 миллионов.
было решено сделать аналог digital trie на базе файловой системы.
однако тест показал, что fs дохнет при 3.2-3.5 миллионах вложеных папок и это без файлов.
пробовал по две цифры на каталог. итого при длине номера 10 знаков, имеем глубину 5.
увеличение вложенности ухудшает ситуацию.
в качестве подопытных пробовал ext2, reiserfs с дефолтными настройками.
так что этот вариант был помечен как нерабочий.

Это следует рассматривать как усугубляющее ситуацию во всех отношениях.
почему ?

DPH3Кстати, сразу советую в список полей добавить:
версию протокола для блобов (ой как пригодится при расширении постановки),
версию самого объекта в блобе (для оптимистических блокировок и прочих радостей работы с блобами).
версия blob внутри. ничего изменяться не будет - тупо хранилище данных за три месяца.
новые данные добавляются по мере поступления.
старые(старше трех месяцев (конфигурабельно)) удаляются каким-нить тупым скриптом по cron раз в день (ночью).

DPH3И, какой характер и число запросов на поиск? Просто поиск одиночных записей по индексу? Или выборка по условиям - если да, то по каким?
вижу как
select * from table where number=n and date >= d1 and date < d2 limit 0, 20 (конфигурабельно)
больше ничего не нужно. ну может быть count еще по этому-же условию.

пока что максимально предполагается до 1000 одновременных запросов. это фантастический максимум.

конвертировать blob объект в таблицы нет смысла. на выходе он нужен именно в том формате, в котором положен в базу. тем более его внутренний формат предполагает наличие опциональных и/или повторяющихся полей и прочих радостей, которые, как понимаю, не очень хорошо ложатся в таблицу.

тоесть по сути это документная база. только документов очень много.

servitЕсть достаточно интересное интервью
читаю, интересно. спасибо!

параллельно пустил тест на xfs с длиной имени поддиректории 3 символа.
24% из 5 миллионов за два часа. слабовато. всеже наверное тупиковый путь.

miksoftAlexey K.параллельно пустил тестЧто за тест?

Кстати, еще одно направление, на которое, имхо, было бы полезно глянуть - key-value хранилища.

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

а можно пример хранилища ? hypertable оно ?

DPH3Ну, я бы все-таки версию протокола наверх вытащил. По личному опыту.
Ну не бывает такого, что бы формат не поменялся. К тому же при имеющихся условиях компактность хранения уже может начать играть свою роль - а это точно предполагает игру с форматами.

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

DPH3Ага. Тогда подумай (и поиграй) с физическим размещением данных - как попало или, например, отсортировано по number.
Может оказаться заметно выгоднее на select (меньше физ. чтений, да и блокировок при удалении).

Кстати, доступность высокая нужна? И какой режим работы - 24*7 или все легче?
А то на выбор БД это тоже оказывает принципиальное значение.
в некотором роде они отсортированы по дате. люди звонят - данные поступают.
режим... добавление/удаление 24*7, чтение 8*5 (коллцентр)

нада опять-таки написать тест и проверить как тот-же постгрес справится с поиском.

miksoftУ меня в этом направлении опыта нет, но эксперименты я бы начал с Memcachedb и Membase, т.к. они имеют отношение к memcached, которая является классикой жанра в Key-value cache in RAM.
благодарю, посмотрю что за звери.


DPH3Так у тебя код обработки будет типа
if (rs.getInt("PROTOCOL").equals(XML_PROTOCOL))
return objectFromXML(rs.getBlob("DATA"))
else
return objectFromXML(rs.getBlob("DATA"))

нет, в этом случае все будет крайне просто
Ipraser* parser = ParserFactory::Get(*data);
parser->GetField(...);
...
и вообще обработка данных проблему не представляет. все уже почти написано.
есть проблема храния и поиска.

DPH3А еще как он справиться с бэкапированием/восстановлением такого объема данных (или репликацией). А то тут стоит сразу думать о подобных проблемах.
raid5 не решит проблему ?
опять же проблема хранилища это не моя проблема :) (с надеждой в голосе...)