перепробовал уже много разных движков. почти отчаялся и смирился с тем что придется делать свою базу на базе (bdb).
суть задачи такая — я делаю мониторинг доступности разных хостов.
предположим он тестирует какой-то хост каждую минуту на какие-то показатели. и надо хранить все результаты тестов за весь период тестирования. сколько бы лет не было. в результате если тестируемых объектов мало, записей в базе теоретически должно быть не очень много.
но рассчитывают что клиентов будет много. и соответственно стал вопрос в том как хранить все эти результаты тестирования. цифры в миллиардах идут и более. для оптимизации можно использовать то что не нужно делать выборки по всему объему данных, а нужны только срезы за день , час и т.д. вопрос такой — умеет ли какая либо база по какому-то критерию разбивать таблицы на блоки. Пример: я запрашиваю у базы — а дай информацию по хосту ya.ru за 2009.10.10 23.00 - 23.15 и она считывает их из псевдотаблицы hour_ya.ru_2009.10.10_23.00.tbl, нужно отчет за день — запрашиваю из псевдотаблицы day_ya.ru_2009.10.10.tbl, и ответ от базы приходит мгновенно а не через 20 минут.
То есть фактически производительность движка ограничивается объемом диска и скоростью чтения с него а не количество процов (так как не надо по огромным индексам бегать).
Есть ли база с таким расширением и как она называется база и расширение ?

если что не правильно объяснил, поправьте попробую подробней описать.

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

miksoft,

фишка в том чтобы база сама разбивала на таблицы и сама где искать

miksoft,

как по английскому называется этот термин который вы указали "предрассчитанные агрегаты"?
и еще, есть необходимость не только в репортах за час,день и месяц но и в самих данных поминутно.
так же решение должно быть экономным, ставить новый сервер из-за того что скорость работы движка меньше скорости прямого чтения с диска — не позволительно

АнатоЛойСам могу сказать по IDB Informix Dynamic Server: и с "fragmenting by expression" и без него (просто с индексами) вполне тебя удовлетворит (предупреждаю - за бабки)...
посмотрел fragmenting — оно не умеет само фрагменты создавать, надо задавать условие.
т.е. нельзя сделать типа услвоие кратность какому-то числу.
insert into table$(ceil(time/86400))
вот вроде такого

miksoftДаже не знаю, а зачем вам?
Это общий принцип, вряд ли вы его найдете в доке по конкретной СУБД.

я пробовал гуглить по этому термину и ничего не нашел :(

miksoft
Это требование ни о чем не говорит, ибо практически у всех СУБД (за исключением in-memory) производительность ограничивается (помимо кривых рук разработчика) именно дисковым вводом/выводом.

ок, пример. вот таблица для MySQL

create table logs (
time datetime not null,
id bigint,
value bigint,
index(time,id)
) ;
в неё вставляется хtera записей и делается запрос вида select * from logs where id = 666 and time between '2009-09-01 22:00:00' and '2009-09-01 23:45:00'; в ответ за скажем 100 мс должен прийти ответ...


у меня нет опыта работы с такими объемами и я не уверен что простая база данных выдержит это... вот поэтому и мудрю

я не прав ? и движок одинакого быстро работает с любыми объемами данных в условиях если я на запрошу срез за месяц а буду запрашивать срезы за период не более нескольки часов ( в данном примере 105 записей ) ?