|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
Приветствую! Я программист-алгоритмист, имею поверхностное представление о системах хранения данных. Теперь столкнулся с необходимостью хранить некоторую информацию персистентно, но не могу найти подходящего для этого решения. Я рассчитываю получить указание на то, какие програмные продукты можно применить для моего случая. Итак, информация, которую я хочу хранить выглядит так: набор таблиц, где таблица - это набор строк. Каждая строка в таблице - набор полей (числа, string-и). Каждая строка таблицы адресуется некоторым id (целое). Каждое поле адресуется его именем (string). Требований к строгой схеме - фиксированному набору полей в каждой строке нет. Модель работы с данными такова: в online мы ничего не читаем из таблиц, а только пишем туда . Примерный набор операций: а) table1[35]["field1"].set("blabla"); // изменение значения поля b) table1[35]["field2"].increment(); // инкремент поля-счётчика c) table1[35].delete(); // удаление строки Чтение из таблиц происходит редко (раз в день или реже), но большими порциями - последовательное вычитывание всей таблицы есть ок. Ну т.е. это сбор информации в онлайне с последующим большим анализом. Цель, требования - минимизация потребления памяти в онлайн, эффективность по времени . Требований к кластеризации пока нет - для наших нагрузок должно хватать одной машинки. Как это можно было бы реализовать самостоятельно: - каждая таблица хранится сортированной по id в отдельном файле - это снапшот - каждая операция в онлайн записывается в инкрементальный xlog на диске - ночью это всё компактизуется: xlog сортируется внешней сортировкой, накатывается на снапшот, получаем новый снапшот - для анализа зачитываем файл с таблицей из снапшота последовательно Делать самому всё это - ой как нехочется. Посоветуйте куда посмотреть: продукты и правильные слова, - как такой паттерн работы называется по-английски. Я вот понял, что похоже это на Data Warehouse, но чего-то легковесного, как я описал, в этой области не нашёл. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 19:40 |
|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
Druh похоже это на Data WarehouseНисколько не похоже. Если вам нужно что то легковесное смотрите в сторону SQLite ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 19:55 |
|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
SERG1257, SQLite умеет не тратить время на запись изменения и производить изменения порциями отложенно, как я описал? Меня не интересует относительная легковесность как таковая. Меня интересует легковесность в том множестве СУБД, которые удовлетворяют описанным мною требованиям. В идеале - если они будут уметь делать только то, что я описал и (как следствие) делать это наиболее эффективно. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 20:01 |
|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
Druh удовлетворяют описанным мною требованиям. В идеале - если они будут уметь делать только то, что я описал и (как следствие) делать это наиболее эффективно.Ваши требования нетипичны для РСУБД. Боюсь под ваши строгие критерии подойдет только ваша собственная разработка. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 20:18 |
|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
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.02.2014, 20:35 |
|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
Druh, Не пожалейте неделю, купите какую нибудь книжку по базам данных, возможно измените свои подходы. Пока Вы рискуете наломать дров ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 21:20 |
|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
SERG1257Druhудовлетворяют описанным мною требованиям. В идеале - если они будут уметь делать только то, что я описал и (как следствие) делать это наиболее эффективно.Ваши требования нетипичны для РСУБД. Боюсь под ваши строгие критерии подойдет только ваша собственная разработка.Странно, а я понял описание задачи наоборот. Имхо, ему любая РСУБД подойдет. Читать и писать они все могут, нагрузки небольшие... ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 22:39 |
|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
Druh, Какой объем данных записывается в сутки? Должно ли решение быть "встраиваемым" в продукт или можно просто поставить на какой-то сервер и запускать там? Насколько велики требования к надежности хранения? Какие требования к надежности всей системы (в процессе записи, например, сбои больше секунды уже очень дорого стоят или можно легко и минут на 15 раз в неделю притормозить) и т.п. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2014, 15:42 |
|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
DPH3, Собственно, отталкиваясь от того алгоритма реализации, который я описал, я ожидаю производительности со скоростью записи жёсткого диска. Никакой речи о задержках на секунду не идёт. Я рассчитываю очень примерно на 100 записей в секунду. При этом общее количество сущностей порядка 100млн. Встраиваемое решение или серверное - не имеет значения. Запись на таких скоростях не должна убираться в throuhput ни сетевой, ни дисковой подсистем. Именно это я имел ввиду, когда говорил, что одной машинки хватит, - не что данных мало, а что есть алгоритм эффективной реализации. Я ищу любое решение (или хотя бы ключевые слова) именно для этого паттерна (быстрая запись и неторопливое bulk-чтение целых таблиц изредка). Похожий паттерн имеет задача быстрой записи логов, где лог-записи (полу-)структурированы, с последующей отдельной обработкой (вроде индексации) и анализом. Про РСУБД (тут это упоминали) я не говорю (если Р означает реляционная). Ни целостность, ни нормализованность, ни схема, ни транзакционность, как можно понять, мне не принципиальны. Тут как минимум NoSQL, но все они всё-таки поддерживают текущее состояние БД онлайн, а мне нежелательно тратить на это ни память, ни время. Вобщем, я прихожу к тому, что ничего готового я, видимо, не найду. Слишком специфичная и простая на первый взгляд задача. Придётся либо писать самому, либо взять за основу что-нибудь из тройки MySQL, MongoDB, Hadoop и надеятся на то, что оно сдюжит. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2014, 23:10 |
|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
Druhя ожидаю производительности со скоростью записи жёсткого диска. Никакой речи о задержках на секунду не идёт. Я рассчитываю очень примерно на 100 записей в секунду. Обычный десктопный SATAII винт обеспечивает запись со скорость 100мб/с. Чтобы он смог писать 100 записей в секунду, каждая запись должна быть размером в мегабайт. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2014, 23:33 |
|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
Druhза основу что-нибудь из тройки MySQL, MongoDB, Hadoop и надеятся на то, что оно сдюжит. непонятно, при чем тут MySQL, или наоборот, при чем тут MongoDB, Hadoop. про "сдюжит" вам уже сказали - 100 записей в секунду это ерунда какая-то. Давно бы уже сотворили прототип на MySQL. В таких делах нужно поменьше теоретизировать. DruhЯ программист-алгоритмист, имею поверхностное представление о системах хранения данных. вот это уже плохо, так что придется осваивать. На MySQL и потренируйтесь. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2014, 23:58 |
|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovОбычный десктопный SATAII винт обеспечивает запись со скорость 100мб/с. Чтобы он смог писать 100 записей в секунду, каждая запись должна быть размером в мегабайт.Нет прямой связи между скоростью последовательной записи и максимальной частотой операций записи. Но, таки, да: предел одиночного диска - 70-150 IOPS. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2014, 16:49 |
|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
Basil A. SidorovНо, таки, да: предел одиночного диска - 70-150 IOPS. тут надо отметить, что речь про ширпотребные SATA II диски, по 100 баксов за штуку. Насчет IOPS - сейчас это легко решается экстенсивным методом, путем покупки SSD - там даже у ширпотреба десятки тысяч IOPS. гораздо полезнее уметь пользоваться калькулятором. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2014, 17:48 |
|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
Basil A. SidorovНет прямой связи между скоростью последовательной записи и максимальной частотой операций записи. Задача аффтара "только писать и почти никогда не читать" отлично укладывается в плоские файлы и последовательную запись. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2014, 19:39 |
|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
DruhСобственно, отталкиваясь от того алгоритма реализации, который я описал, я ожидаю производительности со скоростью записи жёсткого диска. Никакой речи о задержках на секунду не идёт. Я рассчитываю очень примерно на 100 записей в секунду. При этом общее количество сущностей порядка 100млн. Встраиваемое решение или серверное - не имеет значения. Запись на таких скоростях не должна убираться в throuhput ни сетевой, ни дисковой подсистем. Именно это я имел ввиду, когда говорил, что одной машинки хватит, - не что данных мало, а что есть алгоритм эффективной реализации. ... Про РСУБД (тут это упоминали) я не говорю (если Р означает реляционная). Ни целостность, ни нормализованность, ни схема, ни транзакционность, как можно понять, мне не принципиальны. Тут как минимум NoSQL, но все они всё-таки поддерживают текущее состояние БД онлайн, а мне нежелательно тратить на это ни память, ни время. Ну, указывать алгоритм до формулирования требований - это плохой путь ) Сначала надо понять, а какие реальные граничные условия - а уже потом искать подходящий алгоритм решения. Например, 100 записей в секунду не проблема даже для моего ноутбука (для разумных записей) для любой СУБД. Сложности начинаются при: 1) Данные нельзя терять никогда. Нужно решение, которое работает при любых сбоях жесткого диска и вообще железа/ОС. 2) Нужно писать много данных, причем на каждый чих нужен seek и нет денег на нормальное железо. 3) По данным нужен хитрый поиск 4) ... Например, хочу заметить, что у заметной части NoSQL большие проблемы с надежностью, а с диском они работают в лучшем случае через ОС. "Взрослые" РСУБД очень неплохо умеют работать с диском на достаточно низком уровне RAW. DruhЯ ищу любое решение (или хотя бы ключевые слова) именно для этого паттерна (быстрая запись и неторопливое bulk-чтение целых таблиц изредка). Похожий паттерн имеет задача быстрой записи логов, где лог-записи (полу-)структурированы, с последующей отдельной обработкой (вроде индексации) и анализом. Вобщем, я прихожу к тому, что ничего готового я, видимо, не найду. Слишком специфичная и простая на первый взгляд задача. Придётся либо писать самому, либо взять за основу что-нибудь из тройки MySQL, MongoDB, Hadoop и надеятся на то, что оно сдюжит. Вообще, если особая надежность не важна, то подойдет любой нормальный логгер (типа log4j). Писать в разные файлы подряд, потом каким-нибудь awk вычитывать, сортировать как удобно и скармливать анализатору. Производительности хватит с запасом, скрипт для сортировки будет в несколько строчек, писать быстрее, чем прочитать обсуждение на sql.ru ) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2014, 18:47 |
|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovBasil A. SidorovНет прямой связи между скоростью последовательной записи и максимальной частотой операций записи. Задача аффтара "только писать и почти никогда не читать" отлично укладывается в плоские файлы и последовательную запись. подойдет любая база. Таблицы без индексов. Запись будет почти как в плоский файл. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2014, 10:45 |
|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
DPH3 "Взрослые" РСУБД очень неплохо умеют работать с диском на достаточно низком уровне RAW. насколько я помню, уже давно было признано, что RAW не дает значимого преимущества. И уж тем более не обеспечивает "большей надежности". Сбой физического диска это сбой, и похер, какая сверху него прослойка. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2014, 11:42 |
|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
1. Задача описана очень коряво. Выдумывать "что имел в виду аффтор" можно сколько угодно. 2. Судя по всему. есть проблемы в постановке и архитектуре БД - каждая таблица хранится сортированной по id в отдельном файле - это снапшот - каждая операция в онлайн записывается в инкрементальный xlog на диске - ночью это всё компактизуется: xlog сортируется внешней сортировкой, накатывается на снапшот, получаем новый снапшот - для анализа зачитываем файл с таблицей из снапшота последовательно Нормальный подход. 1. Нечто похожее используется в складском софте для управления запасами на складе. Только там хранится последнее состояния + логи как оно к нему пришло. Соответственно всегда можно восстановить запасы на конкретную дату. 2. В Oracle есть Mat View. Что позволяет параллельно вести "таблицы" + хранить снимки. Используется/использовалось в BI /Business Analytics/ для drill down отчетов. С ходу, я бы смотрел возможность под задачу задействовать их. Вообще, мешанина понятий: лог / таблица, всегда пишем / редко читаем. Какой-то сумбур. Обычная задача для кодинга и реализации нормального кеша. Ну и реализуйте нормальный кешь заточенный под Ваши требование + любое хранилище. IMHO Без описания задачи и патерна нагрузки, советовать бесмысленно. Так же не понятно, нафига вам вообще БД. Файлы на диске вполне рулят ))). По производительности будут самое быстрое ))). ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2014, 13:35 |
|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
kdvDPH3 "Взрослые" РСУБД очень неплохо умеют работать с диском на достаточно низком уровне RAW. насколько я помню, уже давно было признано, что RAW не дает значимого преимущества. И уж тем более не обеспечивает "большей надежности". Сбой физического диска это сбой, и похер, какая сверху него прослойка. Обеспечение надежности и RAW - это независимые фичи, разумеется И, конечно, RAW не для надежности. Про эффективность RAW - ничего не могу сказать. DB2шники говорят, что иногда RAW заметно лучше, сам не тестировал. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2014, 17:25 |
|
Посоветуйте БД для проекта
|
|||
---|---|---|---|
#18+
при возникновении темы "Oracle на RAW", Oracle говорил о 10-15% прироста попугая. Как мерили, не понятно. Смысл не столько в RAW и скорости дисков, сколько в том, что нет обращений к ОС. Соответственно не нужна борьба с глюками ОС. Последние, например, на Linux и тестовой системе наблюдал вживую. Когда при full table скан ОС начинала кешировать файлы БД и отдавать память из-под приложения на ненужный многогигабайтный кеш файловой системы. Вылечилось пинанимем админов и настройкой асинхронного ввода-вывода. В ситуации с RAW таких проблем нет по определению. ОС не используется. Все управление на уровне СУБД. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2014, 18:00 |
|
|
start [/forum/topic.php?fid=35&fpage=7&tid=1552393]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
51ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
80ms |
get tp. blocked users: |
2ms |
others: | 250ms |
total: | 426ms |
0 / 0 |