"Alexey Popov" ...
Vlad Khorsun wrote:
Предел номера транзакции,
Причём тут "такие объёмы" ???
Предел в 2 миллиарда транзакций непреодолим.
Ну так не надо в него стучаться лбом - это больно и не нужно :)
В 3-ке сделаем 4млрд. Потом посмотрим на возможность дальнейшего
расширения этого лимита.
Остальные утверждения были больше вопросами
Гм. Наверное я отстал от жизни и разучился читать, но вопросов там не было...
не 100% заполнение страниц данными,
Это к dbf\csv\txt - там 100%.
Если в базу делается только insert и select, то увеличивать размер файла БД в
разы
Это претензия конкретно к ФБ или вообще к БД ?
невозможность кластерных индексов
Это можно принять с бооольшими оговорками. И то только после анализа
запросов, которые ты не показал.
Запросы за интервал времени или последние измерения. С фильтром по множеству
датчиков.
Например если записи перемешать рандомно в таблице, то даже при наличии индекса по времени, будет очень грустно на больших
выборках.
И откуда возьмётся случайное перемешивание, если данные приходят с датчиков
весьма последовательно - т.е. кластеризация по времени и так присутствует
натуральным
образом ?
1. Задачу ты вообще не описал, поэтому говорить что-то конкретное невозможно.
Что тебе ещё хочется знать?
Мне - ничего, это твоя задача и тебе с ней жить :) Меня больше интересуют
реально
слабые места в алгоритмах, реализованных в ФБ, какие их них более критичны и
должны
быть доработаны в первую очередь.
2. Я не говорю, что FB идеально подходит для работы с релаьно большими
объёмами, но
ты не привёл ни одного настоящего аргумента против.
Партиционирование? Быстрое удаление устаревших данных?
Это (партиционирование для удаления устаревших данных) легко сделать и
вручную.
Я тебе больше скажу - можно сделать и шардинг на несколько хостов, например по
ИД датчика. Было бы желание.
--
Хорсун Влад
