powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Посоветуйте БД для проекта
21 сообщений из 21, страница 1 из 1
Посоветуйте БД для проекта
    #38575649
Druh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Приветствую!

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

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

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

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

Делать самому всё это - ой как нехочется. Посоветуйте куда посмотреть: продукты и правильные слова, - как такой паттерн работы называется по-английски. Я вот понял, что похоже это на Data Warehouse, но чего-то легковесного, как я описал, в этой области не нашёл.
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38575656
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Druh похоже это на Data WarehouseНисколько не похоже.
Если вам нужно что то легковесное смотрите в сторону SQLite
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38575660
Druh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257,
SQLite умеет не тратить время на запись изменения и производить изменения порциями отложенно, как я описал? Меня не интересует относительная легковесность как таковая. Меня интересует легковесность в том множестве СУБД, которые удовлетворяют описанным мною требованиям. В идеале - если они будут уметь делать только то, что я описал и (как следствие) делать это наиболее эффективно.
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38575663
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Druh удовлетворяют описанным мною требованиям. В идеале - если они будут уметь делать только то, что я описал и (как следствие) делать это наиболее эффективно.Ваши требования нетипичны для РСУБД. Боюсь под ваши строгие критерии подойдет только ваша собственная разработка.
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38575668
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38575692
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Druh,

Не пожалейте неделю, купите какую нибудь книжку по базам данных, возможно измените свои подходы. Пока Вы рискуете наломать дров
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38575739
rockclimber
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257Druhудовлетворяют описанным мною требованиям. В идеале - если они будут уметь делать только то, что я описал и (как следствие) делать это наиболее эффективно.Ваши требования нетипичны для РСУБД. Боюсь под ваши строгие критерии подойдет только ваша собственная разработка.Странно, а я понял описание задачи наоборот. Имхо, ему любая РСУБД подойдет. Читать и писать они все могут, нагрузки небольшие...
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38576039
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Druh,

Какой объем данных записывается в сутки? Должно ли решение быть "встраиваемым" в продукт или можно просто поставить на какой-то сервер и запускать там?
Насколько велики требования к надежности хранения? Какие требования к надежности всей системы (в процессе записи, например, сбои больше секунды уже очень дорого стоят или можно легко и минут на 15 раз в неделю притормозить) и т.п.
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38576192
Druh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
DPH3,

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

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

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

Вобщем, я прихожу к тому, что ничего готового я, видимо, не найду. Слишком специфичная и простая на первый взгляд задача. Придётся либо писать самому, либо взять за основу что-нибудь из тройки MySQL, MongoDB, Hadoop и надеятся на то, что оно сдюжит.
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38576205
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Druhя ожидаю производительности со скоростью записи жёсткого диска. Никакой речи о
задержках на секунду не идёт. Я рассчитываю очень примерно на 100 записей в секунду.
Обычный десктопный SATAII винт обеспечивает запись со скорость 100мб/с. Чтобы он смог
писать 100 записей в секунду, каждая запись должна быть размером в мегабайт.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38576217
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Druhза основу что-нибудь из тройки MySQL, MongoDB, Hadoop и надеятся на то, что оно сдюжит.
непонятно, при чем тут MySQL, или наоборот, при чем тут MongoDB, Hadoop.
про "сдюжит" вам уже сказали - 100 записей в секунду это ерунда какая-то. Давно бы уже сотворили прототип на MySQL. В таких делах нужно поменьше теоретизировать.

DruhЯ программист-алгоритмист, имею поверхностное представление о системах хранения данных.
вот это уже плохо, так что придется осваивать. На MySQL и потренируйтесь.
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38576362
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovОбычный десктопный SATAII винт обеспечивает запись со скорость 100мб/с. Чтобы он смог
писать 100 записей в секунду, каждая запись должна быть размером в мегабайт.Нет прямой связи между скоростью последовательной записи и максимальной частотой операций записи.
Но, таки, да: предел одиночного диска - 70-150 IOPS.
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38576374
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovНо, таки, да: предел одиночного диска - 70-150 IOPS.
тут надо отметить, что речь про ширпотребные SATA II диски, по 100 баксов за штуку.
Насчет IOPS - сейчас это легко решается экстенсивным методом, путем покупки SSD - там даже у ширпотреба десятки тысяч IOPS.

гораздо полезнее уметь пользоваться калькулятором.
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38576399
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovНет прямой связи между скоростью последовательной записи и
максимальной частотой операций записи.
Задача аффтара "только писать и почти никогда не читать" отлично укладывается в плоские
файлы и последовательную запись.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38577171
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DruhСобственно, отталкиваясь от того алгоритма реализации, который я описал, я ожидаю производительности со скоростью записи жёсткого диска. Никакой речи о задержках на секунду не идёт. Я рассчитываю очень примерно на 100 записей в секунду. При этом общее количество сущностей порядка 100млн. Встраиваемое решение или серверное - не имеет значения. Запись на таких скоростях не должна убираться в throuhput ни сетевой, ни дисковой подсистем. Именно это я имел ввиду, когда говорил, что одной машинки хватит, - не что данных мало, а что есть алгоритм эффективной реализации.
...
Про РСУБД (тут это упоминали) я не говорю (если Р означает реляционная). Ни целостность, ни нормализованность, ни схема, ни транзакционность, как можно понять, мне не принципиальны. Тут как минимум NoSQL, но все они всё-таки поддерживают текущее состояние БД онлайн, а мне нежелательно тратить на это ни память, ни время.

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

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

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

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

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

Вообще, если особая надежность не важна, то подойдет любой нормальный логгер (типа log4j). Писать в разные файлы подряд, потом каким-нибудь awk вычитывать, сортировать как удобно и скармливать анализатору. Производительности хватит с запасом, скрипт для сортировки будет в несколько строчек, писать быстрее, чем прочитать обсуждение на sql.ru )
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38577480
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovBasil A. SidorovНет прямой связи между скоростью последовательной записи и
максимальной частотой операций записи.
Задача аффтара "только писать и почти никогда не читать" отлично укладывается в плоские
файлы и последовательную запись.

подойдет любая база. Таблицы без индексов. Запись будет почти как в плоский файл.
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38578698
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DPH3 "Взрослые" РСУБД очень неплохо умеют работать с диском на достаточно низком уровне RAW.
насколько я помню, уже давно было признано, что RAW не дает значимого преимущества. И уж тем более не обеспечивает "большей надежности".
Сбой физического диска это сбой, и похер, какая сверху него прослойка.
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38578898
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1. Задача описана очень коряво. Выдумывать "что имел в виду аффтор" можно сколько угодно.
2. Судя по всему. есть проблемы в постановке и архитектуре БД

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

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

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

Без описания задачи и патерна нагрузки, советовать бесмысленно. Так же не понятно, нафига вам вообще БД. Файлы на диске вполне рулят ))). По производительности будут самое быстрое ))).
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38579316
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvDPH3 "Взрослые" РСУБД очень неплохо умеют работать с диском на достаточно низком уровне RAW.
насколько я помню, уже давно было признано, что RAW не дает значимого преимущества. И уж тем более не обеспечивает "большей надежности".
Сбой физического диска это сбой, и похер, какая сверху него прослойка.

Обеспечение надежности и RAW - это независимые фичи, разумеется И, конечно, RAW не для надежности.
Про эффективность RAW - ничего не могу сказать. DB2шники говорят, что иногда RAW заметно лучше, сам не тестировал.
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38579363
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
при возникновении темы "Oracle на RAW", Oracle говорил о 10-15% прироста попугая. Как мерили, не понятно.

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

В ситуации с RAW таких проблем нет по определению. ОС не используется. Все управление на уровне СУБД.
...
Рейтинг: 0 / 0
Посоветуйте БД для проекта
    #38579752
DruhПри этом общее количество сущностей порядка 100млн.
Чё-то многовато ...
...
Рейтинг: 0 / 0
21 сообщений из 21, страница 1 из 1
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Посоветуйте БД для проекта
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]