Просветите про базы данных и скорость доступа...

[nt23]

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

Вот у меня есть математическая молотилка, один из главных критетиев - скорость. Данные хранятся в неком внутреннем формате.
Тут человечище говорит, а давай хранить данные в базе данных,
а внутреннего формата не будет вовсе. Т.е. я себе могу представить два
расклада: либо у меня все-таки внутренний формат останется, а тогда зачем база данных; либо я из молотилки на каждом шаге полезу в базу данных.
Работает все примерно так, данные - это упорядоченный набор разных объектов,
над каждым надо выполнить некую операцию, зависящую от типа объекта.
И так много раз.
У объектов будет меняться внутреннее состояние, но их количество, тип и порядок неизменны для данного конкретного вычисления. Количество объектов в разных случаях может быть от десятков до десятков тысяч,
в среднем в районе, скажем, пары сотен.
Вопрос: насколько архитектура с базой данных оправдана, насколько быстро
можно реализовать обращение к базе данных?

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

[Yuri_p33]

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

Другое дело, если кроме просто хранения вам нужно решать и другие задачи - согласованность данных, транзакции, универсальный механизм доступа для разных клиентов и т.п.

[nt23]

Спасибо.
Т.е. я еще не совсем динозавр....

[Frank]

Постановка задачи не совсем ясна.

Возможно, вам надо присмотреться к Berkeley DB: http://www.sleepycat.com/products/documentation.shtml

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

Преимущества: очень простая и быстрая, бесплатная, имеет удобные интерфейсы под все языки программирования.

[Big Cheese]

Согласен с Frank, за исключением того, что Berkeley DB не бесплатная, если ее использовать как часть коммерческой системы, а коммерческая лицензия стоит неизвестно сколько - где-то читал (сорри, не помню точно где), как народ возмущался, что им дали quote на BDB ~$40K...

[A. Fig Lee]

Согласен с Frank, за исключением того, что Berkeley DB не бесплатная, если ее использовать как часть коммерческой системы, а коммерческая лицензия стоит неизвестно сколько - где-то читал (сорри, не помню точно где), как народ возмущался, что им дали quote на BDB ~$40K...

Не уверен, что она thread-safe.
2. Можно использовать старую версию Беркелеы DB - она ИМХО, бесплатная.

[zVlad]

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

Утверждение не верно. Что значит просто для хранения данных? Для этого вообще говоря и магнитные ленты пригодны.
Можно спорить на ящик коньяка (не думаю что кто-нибудь в здравом уме будет спорить), что для многих задач обработки данных - СУБД дают огромный выигрыш в скорости перед просто файлами. И чем сложнее структура данных и запросы - тем больше.
Даже если сравнивать последовательное чтение из файла с table scan, то и то непонятно почему одна и та же операция ввода-вывода должна выполняться дольше для СУБД? Вы скажете данные в случае СУБД надо еще процессором обработать прежде чем отдать? Так на это уйдет 1-2% времени ввода-вывода.

Спасибо.
Т.е. я еще не совсем динозавр....

Дело не в том диназавр Вы или нет. Дело в том, что только специалист по Вашему приложению и в то же время специалист по СУБД мог бы дать корректный ответ на Ваш основной вопрос. По тем намекам что Вы дали, я бы лично воздержался бы советовать что-либо. Кроме того не вреден был бы эксперимент.

.....в отличие от SQL базы, где данные могут выбираться по нескольким ключам.

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

[Yuri_p33]

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

Утверждение не верно. Что значит просто для хранения данных? Для этого вообще говоря и магнитные ленты пригодны.

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

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

[nt23]

Схема такова.
Есть файл с данными. Сейчас я его читаю и строю структуру данных в памяти.
Т.е. дальше все данные в памяти, не на диске.
Мне говорят, ты можешь наделать ошибок, когда строишь структуру данных, а СУБД построит таблицы сама... Вот тут я прочитав предыдущие
сообщения задумался, а где построит. На диске? Тогда мне все ясно.

Могут ли таблицы полностью храниться в памяти? Они не очень большие.
Чего делать с моей структурой данных я понимаю - это называется
Visitor pattern. В классической книжке это место прописано как
for (i.First(); ! i.IsDone(); i.Next())
i.CurrentItem()->Accept(v);
Как это будет выглядеть на таблицах базы данных?

Время обработки здесь не будет время чтения плюс время работы алгоритма.
Для меня это только время работы алгоритма. Потом эти
таблицы/структуры данных не нужны, они не хранятся.

[Frank]

Если хранить данные в субд _не меняя_ алгоритма, то можно ли получить выигрыш. Я пока остаюсь на своем мнении - нет, нельзя.

Главное преимущество базы данных в вашем случае – это индексация. Затрачивается дополнительное время при создании индекса, но зато выборка, удаление, обновление элемента намного быстрее.

Например, вам нужно найти строчку с определённым значением в файле, придётся его просматривать строчка за строчкой, потенциально нужная строка может оказаться в самом конце. В базе же поиск будет происходить по индексу намного быстрее. Про удаление строки из файла и говорить нечего: надо весь файл прочитать и напечатать заново, пропуская эту строку.

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

Вот если вы скачали один раз данные, засунули их в базу, и уже потом работаете с ней, то выигрыш, естественно, будет.

Например, в случае Berkeley DB вам не придётся заново создавать хэш, он сохранится с предыдущего сеанса. Опять же удобно в случае мультизадачности, не надо думать о всяких блокировках, об этом позаботится сама база.

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

Ключ – это не индекс. В BDB я могу по ключу записать что-то в базу и потом выбрать только по этому ключу – классический хэш. В реляционной базе я могу выбирать по нескольким ключам, то бишь полям в базе, соединённым чем-нибудь типа AND или OR.

[Yuri_p33]

Мне говорят, ты можешь наделать ошибок, когда строишь структуру данных, а СУБД построит таблицы сама...

Сама - не построит. Это вам придется думать о том, какие таблицы вы хотите иметь в своей БД. Т.е., создавать схему БД придется вам самому.

Вот тут я прочитав предыдущие сообщения задумался, а где построит. На диске? Тогда мне все ясно. Могут ли таблицы полностью храниться в памяти? Они не очень большие.

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

Чего делать с моей структурой данных я понимаю - это называется Visitor pattern. В классической книжке это место прописано как
for (i.First(); ! i.IsDone(); i.Next())
i.CurrentItem()->Accept(v);
Как это будет выглядеть на таблицах базы данных?

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

[tengiz]

Как уже было сказано выше, хранение данных в СУБД в случае нетривиального порядка доступа к данным (непоследовательное чтение/запись) может дать несколько преимуществ, наиболее очевидные - индексация, кешироване и автоматическая оптимизация доступа к данным. А также возможность возобновить вычисления в случае необходимости перезапуска или после аварийной остановки, обеспечиваемое транзакциями и надёжным хранением. Ещё одно очень важное преимущество при нетривиальном характере доступа - потенциально значительно более высокая производительность при сохранении данных - благодаря наличию журнала транзакций и отложенной записи.

[A. Fig Lee]

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

Вот у меня есть математическая молотилка, один из главных критетиев - скорость. Данные хранятся в неком внутреннем формате.
Тут человечище говорит, а давай хранить данные в базе данных,
а внутреннего формата не будет вовсе. Т.е. я себе могу представить два
расклада: либо у меня все-таки внутренний формат останется, а тогда зачем база данных; либо я из молотилки на каждом шаге полезу в базу данных.
Работает все примерно так, данные - это упорядоченный набор разных объектов,
над каждым надо выполнить некую операцию, зависящую от типа объекта.
И так много раз.
У объектов будет меняться внутреннее состояние, но их количество, тип и порядок неизменны для данного конкретного вычисления. Количество объектов в разных случаях может быть от десятков до десятков тысяч,
в среднем в районе, скажем, пары сотен.
Вопрос: насколько архитектура с базой данных оправдана, насколько быстро
можно реализовать обращение к базе данных?

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

Berkley - лучший вариант. Иначе после каждого изменения обйекта Вам надо будет апдейтить базу данных. Беркли когда подымается, хранит все в мемори. Бейсикалли ето пары кий=валюе.
Обычную ДБ я бы не использовал.

[zVlad]

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

Вот у меня есть математическая молотилка, один из главных критетиев - скорость..................

Berkley - лучший вариант. Иначе после каждого изменения обйекта Вам надо будет апдейтить базу данных. Беркли когда подымается, хранит все в мемори. Бейсикалли ето пары кий=валюе.
Обычную ДБ я бы не использовал.

У обычной ДБ (по крайней мере у DB2) тоже может быть достаточно функциональности чтобы уметь держать данные в памяти - в случае DB2 это называется буфферный пул. DB2 когда "подымается" также может считать критичные данные в мамять. Вероятно и другие "обычные ДБ" могут.
Я вовсе не имею цели убедить автора топика в полезности БД для его приложения. Мне так и не понятна его проблематика. Но по ходу обсуждения затрагиваются вопросы "обычных ДБ", и как то трудно не внести свои три копейки.