109: (Default)
[personal profile] 109
интересная задачка, в кои-то веки. имеется база размером, который лезет в память (скажем, полгига). от которой требуются обычные датабазные операции, но очень быстро. точнее, запись можно не быстро, а вот чтение нужно быстро. просто кэшировать результаты запросов не получится, поскольку запросы представляют собой джойны 4-5 таблиц, 2-3 из которых реально большие.

кажется, что лучшим решением была бы какая-нибудь in-memory database. такие есть вообще? насколько скорость будет выше, чем если все эти таблицы создать в оракле с клаузой CACHE?

(no subject)

Date: 2004-10-20 04:12 pm (UTC)
From: [identity profile] elk.livejournal.com
Я буду в ньюарке в районе вокзала через полчаса-час. может сходим на ланч куданьть? напиши мне gmail ?

АЕ

(no subject)

Date: 2004-10-20 06:41 pm (UTC)
From: [identity profile] 109.livejournal.com
ой, я поздно прочитал.

(no subject)

Date: 2004-10-20 04:43 pm (UTC)
From: (Anonymous)
Слышaл чтo-тo прo eXtremeDB, нo никoгдa с тaким не рaбoтaл.

(no subject)

Date: 2004-10-20 05:55 pm (UTC)
From: [identity profile] alexf.livejournal.com
Разве сам оракул не умеет всю базу в память засосать?

(no subject)

Date: 2004-10-20 06:55 pm (UTC)
From: [identity profile] 109.livejournal.com
мой последний вопрос именно об этом. насколько in-memory tables быстрее оракла с клаузой CACHE.

(no subject)

Date: 2004-10-20 05:55 pm (UTC)
From: [identity profile] ivan-gandhi.livejournal.com
JDatastore? (check out www.borland.com)

(no subject)

Date: 2004-10-20 06:51 pm (UTC)
From: [identity profile] 109.livejournal.com
где написано, что она in-memory?

(no subject)

Date: 2004-10-20 06:54 pm (UTC)
From: [identity profile] kukutz.livejournal.com
А не-DB подойдёт?

Тогда memcached.

(no subject)

Date: 2004-10-20 06:57 pm (UTC)
From: [identity profile] 109.livejournal.com
я же написал: "кэшировать результаты запросов не получится, поскольку запросы представляют собой джойны 4-5 таблиц, 2-3 из которых реально большие". кэшировать только содержимое таблиц? а как тогда джойны делать?

(no subject)

Date: 2004-10-21 12:29 am (UTC)
From: [identity profile] msh.livejournal.com
Посмотри вот это вот http://www.garret.ru/~knizhnik/compare.html

(no subject)

Date: 2004-10-21 03:27 pm (UTC)
From: [identity profile] 109.livejournal.com
спасибо!

изучение показало, что GigaBASE и GOODS интерфейса с C# не имеют, несмотря на заявленное. PERST же оказался ботвой какой-то.

(no subject)

Date: 2004-10-22 01:45 am (UTC)
From: [identity profile] msh.livejournal.com
Мне казалось что имеют. Можно Костю Книжника спросить, если хочешь

если джойны 4-5 таблиц

Date: 2004-10-21 06:07 am (UTC)
From: [identity profile] exceeder.livejournal.com
то тебе нужен обычный MySQL. Там есть в последних версиях MEMORY-таблицы. И работают они жутко быстро.

Если джойн таблиц на 15, да с подколками типа EXISTS, то я бы тогда начал в сторону Оракла смотреть. А так - это как раз, что надо. У мускла адаптивные алгоритмы джойнов, он после десятка запросов все неплохо отоптимизирует. Возможно, тебе так же новые МайСКЛ ст. процедуры пригодятся.

Re: если джойны 4-5 таблиц

Date: 2004-10-21 02:12 pm (UTC)
From: [identity profile] 109.livejournal.com
если джойн на 15 таблиц, то надо смотреть в сторону более лучших девелоперов :-)

(no subject)

Date: 2004-10-21 07:24 am (UTC)
From: [identity profile] yakov-sirotkin.livejournal.com
По-моему тут без конкретной постановки задачи не обойтись, может и CACHE поможет, может памяти нужно будет поставить 10 гигабайт, может только кастомное решение даст нужную производительность, может это в принципе невозможно, потому что пропускной способности канала не хватит, чтобы прокачать результат...

(no subject)

Date: 2004-10-22 07:52 am (UTC)

(no subject)

Date: 2004-10-24 04:25 pm (UTC)
From: [identity profile] syarzhuk.livejournal.com
По-моему, народ делал такой изврат на InterBase. а) создаётся виртуальный диск в памяти; б) основная база сидит в нём; в) делается shadow на нормальном диске, который потихонечку себе синхронизируется

(no subject)

Date: 2004-10-24 07:18 pm (UTC)
From: [identity profile] 109.livejournal.com
в досе, я помню, была утилитка ramdrive. a как в виндах виртуальный диск сделать?

(no subject)

Date: 2004-10-25 04:08 pm (UTC)
From: [identity profile] vsi.livejournal.com
применительно к скуль серверу существует такой финт ушами: все поля всех таблиц, которые могут участвовать в запросах, индексируются. причем не важно как, главное чтобы каждое поле фигурировало в каком-нибудь индексе. это приводит к тому, что, при достаточном объеме памяти скуль сервер вообще не будет обращяться к диску при обработке запросов на чтение, которые затрагивают только индексированные поля. происходит это благодаря тому, что скуль сервер, как, наверно, и всякая б.м. приличная база данных, по возможности хранит индексы в памяти

(no subject)

Date: 2004-10-25 08:55 pm (UTC)
From: [identity profile] 109.livejournal.com
1. про скуль сервер речи ваще не шло :-)
2. по возможности он хранит и не только индексы
3. несмотря на наличие индексов, оптимизатор часто выбирает full scan, и тогда что есть индексы, что их нет...
4. лишние ненужные индексы засирают память, которая могла бы быть использована по прямому назначению

(no subject)

Date: 2004-10-25 11:01 pm (UTC)
From: [identity profile] vsi.livejournal.com
1. скорее всего это будет работать не только со скуль сервером
2. к индексам у баз данных отношение совершенно особенное, они очень сильно старатются хранить их в памяти
3. оптимизатор не полезет в таблицу если все нужные колонки есть в индексах, он данные будет таскать прямо оттуда, в смысле из индексов
4. по прямому назначению это под memory disk? ;)

(no subject)

Date: 2004-10-26 01:23 pm (UTC)
From: [identity profile] 109.livejournal.com
3 - да нет же. если у тебя три условия на три разные колонки, то скорее всего будет full scan, несмотря на индексы.

Profile

109: (Default)
109

March 2019

S M T W T F S
     12
3456789
101112131415 16
17181920212223
24252627282930
31      

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags