Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 Посоветуйте БД для проекта  [new]
Druh
Member

Откуда:
Сообщений: 3
Приветствую!

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

Итак, информация, которую я хочу хранить выглядит так: набор таблиц, где таблица - это набор строк. Каждая строка в таблице - набор полей (числа, string-и). Каждая строка таблицы адресуется некоторым id (целое). Каждое поле адресуется его именем (string). Требований к строгой схеме - фиксированному набору полей в каждой строке нет.
Модель работы с данными такова: в online мы ничего не читаем из таблиц, а только пишем туда. Примерный набор операций:
а) table1[35]["field1"].set("blabla"); // изменение значения поля
b) table1[35]["field2"].increment(); // инкремент поля-счётчика
c) table1[35].delete(); // удаление строки
Чтение из таблиц происходит редко (раз в день или реже), но большими порциями - последовательное вычитывание всей таблицы есть ок.
Ну т.е. это сбор информации в онлайне с последующим большим анализом.

Цель, требования - минимизация потребления памяти в онлайн, эффективность по времени.
Требований к кластеризации пока нет - для наших нагрузок должно хватать одной машинки.

Как это можно было бы реализовать самостоятельно:
- каждая таблица хранится сортированной по id в отдельном файле - это снапшот
- каждая операция в онлайн записывается в инкрементальный xlog на диске
- ночью это всё компактизуется: xlog сортируется внешней сортировкой, накатывается на снапшот, получаем новый снапшот
- для анализа зачитываем файл с таблицей из снапшота последовательно

Делать самому всё это - ой как нехочется. Посоветуйте куда посмотреть: продукты и правильные слова, - как такой паттерн работы называется по-английски. Я вот понял, что похоже это на Data Warehouse, но чего-то легковесного, как я описал, в этой области не нашёл.
28 фев 14, 19:40    [15649050]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
SERG1257
Member

Откуда:
Сообщений: 2933
Druh
похоже это на Data Warehouse
Нисколько не похоже.
Если вам нужно что то легковесное смотрите в сторону SQLite
28 фев 14, 19:55    [15649132]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
Druh
Member

Откуда:
Сообщений: 3
SERG1257,
SQLite умеет не тратить время на запись изменения и производить изменения порциями отложенно, как я описал? Меня не интересует относительная легковесность как таковая. Меня интересует легковесность в том множестве СУБД, которые удовлетворяют описанным мною требованиям. В идеале - если они будут уметь делать только то, что я описал и (как следствие) делать это наиболее эффективно.
28 фев 14, 20:01    [15649164]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
SERG1257
Member

Откуда:
Сообщений: 2933
Druh
удовлетворяют описанным мною требованиям. В идеале - если они будут уметь делать только то, что я описал и (как следствие) делать это наиболее эффективно.
Ваши требования нетипичны для РСУБД. Боюсь под ваши строгие критерии подойдет только ваша собственная разработка.
28 фев 14, 20:18    [15649257]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54803

Druh
Примерный набор операций:
а) table1[35]["field1"].set("blabla"); // изменение значения поля
b) table1[35]["field2"].increment(); // инкремент поля-счётчика
c) table1[35].delete(); // удаление строки

I smell FVMas!

Posted via ActualForum NNTP Server 1.5

28 фев 14, 20:35    [15649342]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Druh,

Не пожалейте неделю, купите какую нибудь книжку по базам данных, возможно измените свои подходы. Пока Вы рискуете наломать дров
28 фев 14, 21:20    [15649586]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
rockclimber
Member

Откуда: у меня в голове опилки?
Сообщений: 11085
SERG1257
Druh
удовлетворяют описанным мною требованиям. В идеале - если они будут уметь делать только то, что я описал и (как следствие) делать это наиболее эффективно.
Ваши требования нетипичны для РСУБД. Боюсь под ваши строгие критерии подойдет только ваша собственная разработка.
Странно, а я понял описание задачи наоборот. Имхо, ему любая РСУБД подойдет. Читать и писать они все могут, нагрузки небольшие...
28 фев 14, 22:39    [15649894]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
DPH3
Member

Откуда:
Сообщений: 456
Druh,

Какой объем данных записывается в сутки? Должно ли решение быть "встраиваемым" в продукт или можно просто поставить на какой-то сервер и запускать там?
Насколько велики требования к надежности хранения? Какие требования к надежности всей системы (в процессе записи, например, сбои больше секунды уже очень дорого стоят или можно легко и минут на 15 раз в неделю притормозить) и т.п.
1 мар 14, 15:42    [15652115]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
Druh
Member

Откуда:
Сообщений: 3
DPH3,

Собственно, отталкиваясь от того алгоритма реализации, который я описал, я ожидаю производительности со скоростью записи жёсткого диска. Никакой речи о задержках на секунду не идёт. Я рассчитываю очень примерно на 100 записей в секунду. При этом общее количество сущностей порядка 100млн. Встраиваемое решение или серверное - не имеет значения. Запись на таких скоростях не должна убираться в throuhput ни сетевой, ни дисковой подсистем. Именно это я имел ввиду, когда говорил, что одной машинки хватит, - не что данных мало, а что есть алгоритм эффективной реализации.

Я ищу любое решение (или хотя бы ключевые слова) именно для этого паттерна (быстрая запись и неторопливое bulk-чтение целых таблиц изредка). Похожий паттерн имеет задача быстрой записи логов, где лог-записи (полу-)структурированы, с последующей отдельной обработкой (вроде индексации) и анализом.

Про РСУБД (тут это упоминали) я не говорю (если Р означает реляционная). Ни целостность, ни нормализованность, ни схема, ни транзакционность, как можно понять, мне не принципиальны. Тут как минимум NoSQL, но все они всё-таки поддерживают текущее состояние БД онлайн, а мне нежелательно тратить на это ни память, ни время.

Вобщем, я прихожу к тому, что ничего готового я, видимо, не найду. Слишком специфичная и простая на первый взгляд задача. Придётся либо писать самому, либо взять за основу что-нибудь из тройки MySQL, MongoDB, Hadoop и надеятся на то, что оно сдюжит.
1 мар 14, 23:10    [15654768]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54803

Druh
я ожидаю производительности со скоростью записи жёсткого диска. Никакой речи о
задержках на секунду не идёт. Я рассчитываю очень примерно на 100 записей в секунду.

Обычный десктопный SATAII винт обеспечивает запись со скорость 100мб/с. Чтобы он смог
писать 100 записей в секунду, каждая запись должна быть размером в мегабайт.

Posted via ActualForum NNTP Server 1.5

1 мар 14, 23:33    [15654945]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30261
Druh
за основу что-нибудь из тройки MySQL, MongoDB, Hadoop и надеятся на то, что оно сдюжит.

непонятно, при чем тут MySQL, или наоборот, при чем тут MongoDB, Hadoop.
про "сдюжит" вам уже сказали - 100 записей в секунду это ерунда какая-то. Давно бы уже сотворили прототип на MySQL. В таких делах нужно поменьше теоретизировать.

Druh
Я программист-алгоритмист, имею поверхностное представление о системах хранения данных.

вот это уже плохо, так что придется осваивать. На MySQL и потренируйтесь.
1 мар 14, 23:58    [15655155]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11473
Dimitry Sibiryakov
Обычный десктопный SATAII винт обеспечивает запись со скорость 100мб/с. Чтобы он смог
писать 100 записей в секунду, каждая запись должна быть размером в мегабайт.
Нет прямой связи между скоростью последовательной записи и максимальной частотой операций записи.
Но, таки, да: предел одиночного диска - 70-150 IOPS.
2 мар 14, 16:49    [15657847]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30261
Basil A. Sidorov
Но, таки, да: предел одиночного диска - 70-150 IOPS.

тут надо отметить, что речь про ширпотребные SATA II диски, по 100 баксов за штуку.
Насчет IOPS - сейчас это легко решается экстенсивным методом, путем покупки SSD - там даже у ширпотреба десятки тысяч IOPS.

гораздо полезнее уметь пользоваться калькулятором.
2 мар 14, 17:48    [15658106]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54803

Basil A. Sidorov
Нет прямой связи между скоростью последовательной записи и
максимальной частотой операций записи.

Задача аффтара "только писать и почти никогда не читать" отлично укладывается в плоские
файлы и последовательную запись.

Posted via ActualForum NNTP Server 1.5

2 мар 14, 19:39    [15658703]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
DPH3
Member

Откуда:
Сообщений: 456
Druh
Собственно, отталкиваясь от того алгоритма реализации, который я описал, я ожидаю производительности со скоростью записи жёсткого диска. Никакой речи о задержках на секунду не идёт. Я рассчитываю очень примерно на 100 записей в секунду. При этом общее количество сущностей порядка 100млн. Встраиваемое решение или серверное - не имеет значения. Запись на таких скоростях не должна убираться в throuhput ни сетевой, ни дисковой подсистем. Именно это я имел ввиду, когда говорил, что одной машинки хватит, - не что данных мало, а что есть алгоритм эффективной реализации.
...
Про РСУБД (тут это упоминали) я не говорю (если Р означает реляционная). Ни целостность, ни нормализованность, ни схема, ни транзакционность, как можно понять, мне не принципиальны. Тут как минимум NoSQL, но все они всё-таки поддерживают текущее состояние БД онлайн, а мне нежелательно тратить на это ни память, ни время.

Ну, указывать алгоритм до формулирования требований - это плохой путь )
Сначала надо понять, а какие реальные граничные условия - а уже потом искать подходящий алгоритм решения.
Например, 100 записей в секунду не проблема даже для моего ноутбука (для разумных записей) для любой СУБД.

Сложности начинаются при:
1) Данные нельзя терять никогда. Нужно решение, которое работает при любых сбоях жесткого диска и вообще железа/ОС.
2) Нужно писать много данных, причем на каждый чих нужен seek и нет денег на нормальное железо.
3) По данным нужен хитрый поиск
4) ...

Например, хочу заметить, что у заметной части NoSQL большие проблемы с надежностью, а с диском они работают в лучшем случае через ОС. "Взрослые" РСУБД очень неплохо умеют работать с диском на достаточно низком уровне RAW.

Druh
Я ищу любое решение (или хотя бы ключевые слова) именно для этого паттерна (быстрая запись и неторопливое bulk-чтение целых таблиц изредка). Похожий паттерн имеет задача быстрой записи логов, где лог-записи (полу-)структурированы, с последующей отдельной обработкой (вроде индексации) и анализом.

Вобщем, я прихожу к тому, что ничего готового я, видимо, не найду. Слишком специфичная и простая на первый взгляд задача. Придётся либо писать самому, либо взять за основу что-нибудь из тройки MySQL, MongoDB, Hadoop и надеятся на то, что оно сдюжит.


Вообще, если особая надежность не важна, то подойдет любой нормальный логгер (типа log4j). Писать в разные файлы подряд, потом каким-нибудь awk вычитывать, сортировать как удобно и скармливать анализатору. Производительности хватит с запасом, скрипт для сортировки будет в несколько строчек, писать быстрее, чем прочитать обсуждение на sql.ru )
3 мар 14, 18:47    [15665058]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3795
Dimitry Sibiryakov
Basil A. Sidorov
Нет прямой связи между скоростью последовательной записи и
максимальной частотой операций записи.

Задача аффтара "только писать и почти никогда не читать" отлично укладывается в плоские
файлы и последовательную запись.

подойдет любая база. Таблицы без индексов. Запись будет почти как в плоский файл.
4 мар 14, 10:45    [15667751]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30261
DPH3
"Взрослые" РСУБД очень неплохо умеют работать с диском на достаточно низком уровне RAW.

насколько я помню, уже давно было признано, что RAW не дает значимого преимущества. И уж тем более не обеспечивает "большей надежности".
Сбой физического диска это сбой, и похер, какая сверху него прослойка.
5 мар 14, 11:42    [15675335]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9892
1. Задача описана очень коряво. Выдумывать "что имел в виду аффтор" можно сколько угодно.
2. Судя по всему. есть проблемы в постановке и архитектуре БД
+

- каждая таблица хранится сортированной по id в отдельном файле - это снапшот
- каждая операция в онлайн записывается в инкрементальный xlog на диске
- ночью это всё компактизуется: xlog сортируется внешней сортировкой, накатывается на снапшот, получаем новый снапшот
- для анализа зачитываем файл с таблицей из снапшота последовательно

Нормальный подход.
1. Нечто похожее используется в складском софте для управления запасами на складе. Только там хранится последнее состояния + логи как оно к нему пришло. Соответственно всегда можно восстановить запасы на конкретную дату.
2. В Oracle есть Mat View. Что позволяет параллельно вести "таблицы" + хранить снимки. Используется/использовалось в BI /Business Analytics/ для drill down отчетов. С ходу, я бы смотрел возможность под задачу задействовать их.

Вообще, мешанина понятий: лог / таблица, всегда пишем / редко читаем. Какой-то сумбур. Обычная задача для кодинга и реализации нормального кеша. Ну и реализуйте нормальный кешь заточенный под Ваши требование + любое хранилище. IMHO

Без описания задачи и патерна нагрузки, советовать бесмысленно. Так же не понятно, нафига вам вообще БД. Файлы на диске вполне рулят ))). По производительности будут самое быстрое ))).
5 мар 14, 13:35    [15676656]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
DPH3
Member

Откуда:
Сообщений: 456
kdv
DPH3
"Взрослые" РСУБД очень неплохо умеют работать с диском на достаточно низком уровне RAW.

насколько я помню, уже давно было признано, что RAW не дает значимого преимущества. И уж тем более не обеспечивает "большей надежности".
Сбой физического диска это сбой, и похер, какая сверху него прослойка.


Обеспечение надежности и RAW - это независимые фичи, разумеется И, конечно, RAW не для надежности.
Про эффективность RAW - ничего не могу сказать. DB2шники говорят, что иногда RAW заметно лучше, сам не тестировал.
5 мар 14, 17:25    [15678553]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9892
при возникновении темы "Oracle на RAW", Oracle говорил о 10-15% прироста попугая. Как мерили, не понятно.

Смысл не столько в RAW и скорости дисков, сколько в том, что нет обращений к ОС. Соответственно не нужна борьба с глюками ОС. Последние, например, на Linux и тестовой системе наблюдал вживую. Когда при full table скан ОС начинала кешировать файлы БД и отдавать память из-под приложения на ненужный многогигабайтный кеш файловой системы. Вылечилось пинанимем админов и настройкой асинхронного ввода-вывода.

В ситуации с RAW таких проблем нет по определению. ОС не используется. Все управление на уровне СУБД.
5 мар 14, 18:00    [15678781]     Ответить | Цитировать Сообщить модератору
 Re: Посоветуйте БД для проекта  [new]
Вильгельм Холтофф
Guest
Druh
При этом общее количество сущностей порядка 100млн.

Чё-то многовато ...
6 мар 14, 10:05    [15680795]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить