По железу есть: Core i7, 32 GB RAM, 2x2 TB HDD (пока сервер голый, если что, есть возможность поменять на более мощный)

Основная составляющая система – база данных. В данный момент думаю MySQL (так как есть опыт именно с ней). И так большую часть времени будут идти одни инсерты, периодически будут делаться выборки по 500-2000 строк (иногда апдейты). Ожидаемое количество записей во всей БД 1-4 миллиарда (для начала). Больших таблиц будет немного, думаю около 5 (поля в основном varchar, int, tinytext), при этом одна таблица будет на себя брать около 80% всех записей. Собственно у меня вопросы:

1-4 миллиарда для MySQL много. Не потому, что она какая-то неполноценная -- такие объёмы и для промышленных СУБД будут большими. Тут надо columnstore и/или сжатие. Это всё mySQL не умеет.
С columnstore у меня как раз 2 миллиарда на тестовой машине на 16Gb и 8 процов был тестовый набор данных (dbPedia).
Т.е. для columnstore это вообще семечки.

Сейчас вам будут плести про партиции и/или NDB кластеры ...
Пустое это всё. Ключ к решению не там. Партицирование уменьшает объём раз в 10-1000. И это только если удаётся в запросе обрезать лишние партиции оптимизатору (т.е. например запрос за период, хранящийся в одной партиции).
А если нет -- это уже не поможет.
А columnstore работает всегда, во всех запросах.

1. Сколько записей может поместить в себя MySQL? (есть ли ограничения на 1 таблицу?)
2. Какой объем данных может выдержать БД?

Это очень сложно, надо внимательно читать лимиты. Описание mySQL.
И некоторые определяются операционкой. И не забудь заранее определиться с engine.


3. Получится ли делать выборки как описано выше (нужно чтобы запросы были не более 2-4 сек, это естественно учетом того, что везде, где только можно будут индексы)?

Зависит от запросов, данных, таблиц, индексов.

4. Справится ли этим всем MySQL или лучше другую БД (какую?)

Это тебе никто не скажет. Потому что никто не знает.

5. Имеет ли смысл сделать 2 или более БД для ускорения работы (учитывая, что на сервере 2 винта)? Может есть смысл сделать несколько однотипных таблиц, ускорит ли это работу?

Нет, очевидно. Это уменьшение сложности всего лишь в 2 раза. Ну, будет у тебя не 4 миллиарда а 2. Легче ?

6. Что делать если понадобиться хранить 100 миллиардов записей?
7. Какую ОС для этого всего лучше выбрать?

ОС тут мало что решает. Решает СУБД.

Попробуй также поглядеть на Virtuoso open source 7 (лучше на V7, V6 много хуже в этом смысле).
Это как раз та СУБД, с которой я работал. Там серьёзные игры на нескольких миллиардах записей только начинаются.
Также можно глянуть на другие Columnstore СУБД, хвалят вроде бы vertica.

lavrovMasterZiv,

спасибо за развернутый ответ! А что скажите про MSSQL? Опыт работы у меня с ней есть, я почитал она вроде может держать очень большие объемы данных (про скорость только пока не читал).

Держать, то она может что угодно, можно было бы ещё с этим работать, вот вопрос.

Для row wise большие объемы — миллионы записей. Для column store десятки миллиардов.

Впрочем, ты конечно же можешь попробовать и то, и другое, и третье.

Если замутишь с virtuoso — я и Iv_an_ru тут.

Странно другое. Почему не я занимаюсь такими проектами.

lavrovMasterZiv, извиняюсь за глупый вопрос, columnstore оно как раз и есть в mssql?

До сих пор вроде не было....
Если есть — давай ссылку на доку...

Вот, нашел....

www.t-sql.ru/post/columnstore_index_faq.aspx

фициальный выход запланированный на 01 апреля 2012.


В какой версии SQL Server впервые появились колоночные индексы (Columnstore Indexes)?

Колоночные индексы впервые появились в SQL Server Denali CTP 3 и являются одной из ключевых фич (feature) новой версии SQL Server 2012. Разработаны в рамках проекта Аполлон (Apollo).

Что такое Apollo?

Apollo (Аполлон) - кодовое название одного из проектов в рамках разработки SQL Server 2012. Основная цель проекта - уменьшить TCO (Total cost of ownership) существенным ускорением запросов к хранилищу данных (data warehouse). В рамках этого проекта в SQL Server появились две новых технологии: колоночные индексы (Columnstore Indexes) и векторная обработка запросов, названная пакетной обработкой (batches).


Тоже что-то делают...