интересная задачка, в кои-то веки. имеется база размером, который лезет в память (скажем, полгига). от которой требуются обычные датабазные операции, но очень быстро. точнее, запись можно не быстро, а вот чтение нужно быстро. просто кэшировать результаты запросов не получится, поскольку запросы представляют собой джойны 4-5 таблиц, 2-3 из которых реально большие.
кажется, что лучшим решением была бы какая-нибудь in-memory database. такие есть вообще? насколько скорость будет выше, чем если все эти таблицы создать в оракле с клаузой CACHE?
кажется, что лучшим решением была бы какая-нибудь in-memory database. такие есть вообще? насколько скорость будет выше, чем если все эти таблицы создать в оракле с клаузой CACHE?
(no subject)
Date: 2004-10-20 04:12 pm (UTC)АЕ
(no subject)
Date: 2004-10-20 06:41 pm (UTC)(no subject)
Date: 2004-10-20 04:43 pm (UTC)(no subject)
Date: 2004-10-20 05:55 pm (UTC)(no subject)
Date: 2004-10-20 06:55 pm (UTC)(no subject)
Date: 2004-10-20 05:55 pm (UTC)(no subject)
Date: 2004-10-20 06:51 pm (UTC)(no subject)
Date: 2004-10-20 06:54 pm (UTC)Тогда memcached.
(no subject)
Date: 2004-10-20 06:57 pm (UTC)(no subject)
Date: 2004-10-21 12:29 am (UTC)(no subject)
Date: 2004-10-21 03:27 pm (UTC)изучение показало, что GigaBASE и GOODS интерфейса с C# не имеют, несмотря на заявленное. PERST же оказался ботвой какой-то.
(no subject)
Date: 2004-10-22 01:45 am (UTC)если джойны 4-5 таблиц
Date: 2004-10-21 06:07 am (UTC)Если джойн таблиц на 15, да с подколками типа EXISTS, то я бы тогда начал в сторону Оракла смотреть. А так - это как раз, что надо. У мускла адаптивные алгоритмы джойнов, он после десятка запросов все неплохо отоптимизирует. Возможно, тебе так же новые МайСКЛ ст. процедуры пригодятся.
Re: если джойны 4-5 таблиц
Date: 2004-10-21 02:12 pm (UTC)(no subject)
Date: 2004-10-21 07:24 am (UTC)(no subject)
Date: 2004-10-22 07:52 am (UTC)(no subject)
Date: 2004-10-24 04:25 pm (UTC)(no subject)
Date: 2004-10-24 07:18 pm (UTC)(no subject)
Date: 2004-10-25 04:08 pm (UTC)(no subject)
Date: 2004-10-25 08:55 pm (UTC)2. по возможности он хранит и не только индексы
3. несмотря на наличие индексов, оптимизатор часто выбирает full scan, и тогда что есть индексы, что их нет...
4. лишние ненужные индексы засирают память, которая могла бы быть использована по прямому назначению
(no subject)
Date: 2004-10-25 11:01 pm (UTC)2. к индексам у баз данных отношение совершенно особенное, они очень сильно старатются хранить их в памяти
3. оптимизатор не полезет в таблицу если все нужные колонки есть в индексах, он данные будет таскать прямо оттуда, в смысле из индексов
4. по прямому назначению это под memory disk? ;)
(no subject)
Date: 2004-10-26 01:23 pm (UTC)