Здравствуйте, AnonThisTime, Вы писали:

ATT>вы реально не видите разницу надержности винта (а уж про РЕЙД я вообще молчу) и данных в памяти? Если в ДЦ ударит молния, то в вашем случае клиент восстановит данные за не позднее, чем была размер паузы между бекапами (часто системы делают бекапа чаще 1 раз в день?). В случае НДД, человек просто подымет инстанс ОС и проверит данные на целостность, без потери оперативных данных.

данные хранятся на винте в виде snapshot-а и транзакционного лога, при каждом апдейте команды пишутся в лог а потом применяются в данным в памяти. периодически выдается команда checkpoint, которая инициирует создание нового снэпшота и очистку транзакционного лога
если сделать запись в транзакционный лог синхронной, то будет strong durability, если же писать туда асинхронно, то relaxed durability с inconsistency окном в несколько миллисекунд

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Здравствуйте, BubbleWrap, Вы писали:

SVZ>Ты действительно считаешь, что БД общего назначения будет эффективнее специально заточенных структур данных? Особенно для случая, когда, цитирую, "...с ними нужно работать очень интенсивно..."?

думаю что эффективнее специально заточенных не будет, но будет очень хорошо, ведь приложение "знает" как оно работает с данными и может "подсказать" такой БД как правильно индексировать данные!

BW>почему ненадежно? данные ведь не только в памяти хранятся, они записываются на диск и реплицируются на множество машин. я еще не делал репликацию, но тем не менее могу сказать что main memory db может быть очень надежна.
BW>Кэш работает хуже, во первых потому что кэшируются не все данные(у меня все данные в памяти), еще нужна поддержка целостности этого кэша, во вторых потому, что дизайн РБД не позволяет работать быстро. Все структуры данных, которые используют РБД для хранения данных оптимизированы для быстрой работы с диском, не с памятью.
Это неправда. Бд оч сильно оптимизированы для быстрой работы в том числе и с памятью. Пара примеров, дабы не быть голословным
-8кб страницы в MSSQL и до 32кб в оракле выбраны в основном потому что влезают в L1 кэш при таких размерах
-если почитать покойного кэна хендерсона The Guru's Guide to SQL Server Architecture and Internals, то он упоминал о том что в MSSQL даже положение кода оптимизировано так чтобы он по возможности оставался в L1D кэше на типичных операциях
-пол уайт недавно опубликовал интересую статью, в ней написано что для поиска в листовых страницах используется не бинарный поиск а линейная регрессия и это ощутимо влияет на производительность
http://sqlblog.com/blogs/paul_white/archive/2011/08/09/sql-server-seeks-and-binary-search.aspx
-б-пульная хэш-таблица секционируется по нума-нодам, источник не помню, но если надо будет — найду
Это уже не говоря о том что есть query optimizer, статы, и куча эвристик.

В 2006 или 7 я работал с TimesTen и знаете какой бонус она давала? В лучшем случае в 2 раза всего-то.
Короче дохлый номер все это, РСУБД из большой тройки всех рвут просто за счет того что умнее.

Здравствуйте, BubbleWrap, Вы писали:

ATT>>2) целостность там поддерживать ибо логика работы кеша элементарна — thread-safe список объектов. Ну плюс возможно "индексы" можно прикрутить для быстрого поиска.
BW>кэш не может сравниться с in memory db вот почему — допустим у нас есть данные, которые всем очень нужны и к ним часто обращаются, теперь представим, что один из клиентов их изменяет. в случае кэша произойдет инвалидация старых данных и при следующем чтении они не будут в кэше, в случае in memory db — будут. для некоторых приложений это может быть критично (вот только для каких — хз)

Вы что-то попутали! Запись произойдет сначала в кэш, а потом фоновым процессом сбрасывается на диск! Так что кэш будет всегда валидным!

Здравствуйте, Аноним, Вы писали:

А>Дано — прототип объектной main memory базы данных, умеющей транзакции(ACID) и выполнять запросы (пока что только простые). Эта штука рассчитана на очень интенсивную работу с данными (чтение одного объекта в режиме случайного доступа — меньше одной микросекунды, несколько тысяч транзакций в сек. на одной машине) при относительно небольших объемах данных — сотни мегабайт/несколько гигабайт. Теперь собственно вопрос — где это можно использовать если довести до ума?

Технологические системы работающие в режиме реального времени (но по моему здесь уже всё занято SCADA), и задачи в этой области будут очень узкими.
Всё где нужна аналитика в реальном времени и аналитика которая проводиться не на текущих данных (текущие данные успешно заняты SCADA).
Онлайн-игры это вообще идеал для объектной main memory (здесь нужна обязательная кластеризация). Смотри куда идет дядя Миша с VoltDB.

Здравствуйте, rm822, Вы писали:

BW>>почему ненадежно? данные ведь не только в памяти хранятся, они записываются на диск и реплицируются на множество машин. я еще не делал репликацию, но тем не менее могу сказать что main memory db может быть очень надежна.
BW>>Кэш работает хуже, во первых потому что кэшируются не все данные(у меня все данные в памяти), еще нужна поддержка целостности этого кэша, во вторых потому, что дизайн РБД не позволяет работать быстро. Все структуры данных, которые используют РБД для хранения данных оптимизированы для быстрой работы с диском, не с памятью.

R>Это неправда. Бд оч сильно оптимизированы для быстрой работы в том числе и с памятью. Пара примеров, дабы не быть голословным

Именно так, БД оптимизированы для работы и с диском, и с памятью. Ваши примеры подтверждают лишь принцип, что в любой системе, интенсивно работающей с данными, работа с памятью должна быть оптимизирована и оптимизируется.

С другой стороны, в in-memory БД можно сделать некоторые допущения и применить алгоритмы, структуры данных и техники оптимизации, которых в традиционных БД сделать и применить нельзя или нежелательно. Поэтому они действительно могут обрабатывать и выдавать данные быстрее.

R>Это уже не говоря о том что есть query optimizer, статы, и куча эвристик.

R>В 2006 или 7 я работал с TimesTen и знаете какой бонус она давала? В лучшем случае в 2 раза всего-то.

Я более чем уверен, что вы "просто не сумели ее приготовить". Я работал с TimesTen с 2009, c версии 7.0.5 (возможно вы с более старыми); и бонус она давала весьма приличный. После переноса туда части данных и нагрузки, загрузка CPU на сервере с основной БД в пиковые часы снизилась с 85-90% до 30%.

R>Короче дохлый номер все это, РСУБД из большой тройки всех рвут просто за счет того что умнее.

Это верно с небольшой поправкой: "рвут всех остальных традиционных РСУБД". Однако не нужно забывать, что востребованность СУБД на рынке (о чем собственно данная тема) определяется не только быстродействием в тестах и положением в рейтинге "самых-самых быстрых2.

On 02.09.2011 14:40, wildwind wrote:
> R>В 2006 или 7 я работал с TimesTen и знаете какой бонус она давала? В лучшем случае в 2 раза всего-то.
>
> Я более чем уверен, что вы "просто не сумели ее приготовить". Я работал с TimesTen с 2009, c версии 7.0.5 (возможно вы с более старыми); и бонус она давала весьма приличный. После переноса туда части данных и нагрузки, загрузка CPU на сервере с основной БД в пиковые часы снизилась с 85-90% до 30%.

С TimesTen по сети — особо никакой разницы, через shared memory — эффект ощутимый, но
пришлось отказаться т.к. нужно решение доступное по сети.
Да и цена у него кусается.

Здравствуйте, kingu, Вы писали:

K>С TimesTen по сети — особо никакой разницы, через shared memory — эффект ощутимый, но
K>пришлось отказаться т.к. нужно решение доступное по сети.

Никакой разницы с чем? Я описывал тоже работу по сети.

K>Да и цена у него кусается.
Согласен (как и на СУБД "большой тройки" кстати). Но свое применение он находит.

W>Именно так, БД оптимизированы для работы и с диском, и с памятью. Ваши примеры подтверждают лишь принцип, что в любой системе, интенсивно работающей с данными, работа с памятью должна быть оптимизирована и оптимизируется.
W>С другой стороны, в in-memory БД можно сделать некоторые допущения и применить алгоритмы, структуры данных и техники оптимизации, которых в традиционных БД сделать и применить нельзя или нежелательно. Поэтому они действительно могут обрабатывать и выдавать данные быстрее.
Да все верно. Только из факта оптимизации обычных БД очевидно следует что ин-мемори никакого чуда не совершат. А для перехода с одной БД на другую нужно именно чудо = минимум 10кратное превосходство ибо процесс перехода с одной БД на другую тяжелый, сложный и дорогой.
Когда я рассматривал таймстен в комплекте с кучей других подобных технологий мне нужно было именно чудо, 20кратный прирост производительности гарантировал переход, 5кратный гарантировал что его не будет.
Кстати среди этих технологий были и объектные БД — cache, versant, fastdb