LINUX.ORG.RU

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

 


0

3

Здравствуйте. По биллинговым нуждам необходима база, размер которой будет увеличиваться примерно на 8-10к строк в час.

Подскажите, пожалуйста, какую СУБД выбрать? Ограничений по вычислительным мощностям и лицензиям нет. Годный опыт работы только с MySQL

★★★

MongoDB, например.

anonymous
()

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

BattleCoder ★★★★★
()

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

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

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

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

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от monk

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

monk ★★★★★
()

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

MySQL

Deleted
()
Ответ на: комментарий от BattleCoder

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

disee ★★★
() автор топика
Ответ на: комментарий от monk

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

disee ★★★
() автор топика
Ответ на: комментарий от disee

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

BattleCoder ★★★★★
()

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

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

Alve ★★★★★
()
Ответ на: комментарий от disee

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

anonymous
()

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

vtVitus ★★★★★
()
Ответ на: комментарий от disee

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

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

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

monk ★★★★★
()

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

dizza ★★★★★
()
Ответ на: комментарий от vtVitus

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

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

monk ★★★★★
()
Ответ на: комментарий от monk

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

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

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

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

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

vtVitus ★★★★★
()
Ответ на: комментарий от vtVitus

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

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

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

monk ★★★★★
()
Ответ на: комментарий от monk

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

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

vtVitus ★★★★★
()
Ответ на: комментарий от disee

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

vtVitus ★★★★★
()
9 июля 2015 г.
Ответ на: комментарий от disee

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

Iron_Bug ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.