выбор СУБД для большой базы

MongoDB, например.

А увеличиваться будет до какого-то предела? Есть ли какая-то предварительная оценка максимального объёма данных?

Биллинг то какой? самописный что ле?

размер которой будет увеличиваться примерно на 8-10к строк в чаc

Годный опыт работы только с MySQL

Я в 2002 году биллинг делал на MySQL. Сервер на P-2 вполне успешно тащил +1000 строк в минуту.

Разумные предположения: 10к в час = 10к * 24 * 365 = 87600к в год. Значит лет 10-50 MySQL будет работать без проблем...

Основной вопрос: какого типа запросы. Если одна большая таблица и один поток записи, то MySQL выше крыши. Если запросы известны заранее (SQL не нужен) и хочется очень быстро, то можно в сторону redis посмотреть.

Годный опыт работы только с MySQL

MySQL

Данные надо будет хранить порядка 5-10 лет. Как удачно подсчитали ниже это примерно 876.000.000 строк.

Самописный, но тесно интегрирован с решениями от hp

Одна большая таблица, один поток, без UPDATE'ов. Запросы заранее известны и должны отрабатывать раз в неделю

mariaDB?

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

Подскажите, пожалуйста, какую СУБД выбрать?

Только Postgresql. Он в использовании мало отличается от MySQL, но намного большее умеет, качество кода выше, избавлен от некоторых весьма неприятных недостатков MySQL'я

MySQL нормально. Повесишь триггер на вставку, пусть обновляет таблицу (или таблицы) с данными которые нужно отдавать пользователям

Для билинговых данных в 90% необходима поддержка портиций. Из свободных это postgresql http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html . Из несвободных это oracle. так же обычно (90%) данные перед заливкой в базу необходимо обрабатывать по нужным агрегациям, так что «одна табличка» это означает самое начало пути в понимании чего такое биллинг :).

Одна большая таблица, один поток, без UPDATE'ов. Запросы заранее известны и должны отрабатывать раз в неделю

Тогда точно всё равно что. Хоть текстовый файл + logrotate.

Если знаешь MySQL, то лучше всего его.

Я бы взял postrgesql + партицирование.

Для билинговых данных в 90% необходима поддержка портиций.

А смысл? Индексы есть, сложность O(log N), до сотни миллионов записей даже в память влазит. И по чем партицировать? По пользователям/периодам/их комбинации?

Партиции делаются обычно по дате записи.

до сотни миллионов записей даже в память влазит.

это зависит от того чего и как именно хранится. ни в телефоном ни в инет биллинге не видел способа хранения, чтоб 100м лежало в памяти. тем более в памяти не нужны все данные, а нужны в 90% случаях только актуальные для этого и используют партиции.

Индексы есть, сложность O(log N)

Сложность чего? сферического запроса в вакууме ? :D Индексы так же можно резать по партициям во всяком случае в оракле. Это _очень_ серьёзно увеличивает производительность запросов с участием критерия партицирования.

Это _очень_ серьёзно увеличивает производительность запросов с участием критерия партицирования.

Непонятно за счёт чего. Если условие стоит вида BETWEEN по полю партицирования, то без него, если поле является основным (физическим) индексом, то всё равно непартицированный файл будет читаться последовательно по диапазону между начальной и конечной записью.

А сравнивать с вторичным индексом просто некорректно

Непонятно за счёт чего.

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

Kyoto Cabinet

Скажите, а Выделение разделов это не то-же самое?

Или, вероятно, я что-то не допонимаю

примерно да. только я с мускулем не шибко дружен, поэтому подводных камней с ними в нем не знаю.

Teradata Database

если тесно интегрирован, то смотри, что используют hp. для простой писанины в базу с такой маленькой нагрузкой подойдёт практически что угодно. вопрос в том, что потом собираются делать с этими данными. если это просто логи, которые должны храниться, то можно вообще nosql взять какой-нить. а если это данные «живые» и по ним бегают запросы - тогда надо думать в сторону того, какие там будут запросы и насколько часто будут их дёргать. это и будет определять нагрузку.