Юникс вэй

Комментарии

---

@ 31.3.08, 12:00, Lynx
с документом ознакомился

@ 31.3.08, 12:08, Линуксоид
Ну и как тебе результаты? Мне вот кажется, что D3 не хватает подобного документика

@ 31.3.08, 12:49, Stan
Забавно понаблюдать.
Только 4 пример немного смутил.
Перекрестные запросы должны проходить много быстрее линейных (по одному полю). Вот "Поиск по имени, фамилии, улице и почтовому индексу" долже на многомерном массиве проходить быстрее, а на реляционной это должен быть самый длительный запрос.

@ 31.3.08, 14:00, Lynx
эм.. Линуксоид, как бы мне это выразиться поделикатнее: для определенного круга задач, несомненно, имеет смысл рассмотреть возможность использования многомерных СУБД в замен классических реляционных

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

кроме того, документ в приведенном виде представляет лишь маркетинговый интерес

@ 31.3.08, 14:07, Линуксоид
2Stan: логика в Cache' несколько иная. Я бы даже сказал, что она не multi value, потому перекрестные запросы не факт что будут выполняться быстрее. Cache' работает с объектами. В oracle же с учетом оптимизации данных и алгоритма интеллектуального кэширования, возможно выполнение перекрестного запроса без значительного снижения производительности. Опять же, в документе не указан уровень нормали, к которому приведены БД.

2Lynx: естественно, документ маркетинговый. Но именно такого документа и не хватает D3 для полноценного представления себя на рынке.

@ 31.3.08, 14:10, Lynx
Stan, я тоже обратил внимание на данный интересный феномен, скорее всего неудачно или, в случае с 3-м условием, удачно построенные индексы, ну или выборка с 3-м условием возвращает очень небольшие объемы данных, поэтому основные временные затраты лежат за пределами работы самой СУБД, что согласуется с утверждением документа о том, что объем реляционной СУБД для того же самого объема данных, что и для многомерной СУБД в 10 раз больше

@ 31.3.08, 17:12, Stan
Линуксоид, каков же должен быть размер кэша, что бы 60Гб базу принять?! Здесь кэш должен быть на стороне Caché (сорри за каламбур).
Кстати да, в документе не указан уровень нормали БД.

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

@ 31.3.08, 20:58, Lynx
в документе вообще мало чего указано, кроме времени выполнения запросов тут можно лишь надеятся, что проводилось объективное сравнение и разработчики обоих систем знали, что делать и делали это оптимальным способом по критерию: скорость выборки

@ 1.4.08, 08:59, Линуксоид
Я бы не поверил этому документу, если бы внизу не было приписки, что они смогут для меня под мое приложение протестировать. Это только дает повод мне думать, что документ не фуфло, а все таки более-менее реально отображает положение вещей.
Хотя, опять же, все написанное в pdf не исключает изначально кривую структуру БД, неверно или неэффективно созданные индексы и прочее.

@ 1.4.08, 12:02, Lynx
хорошо, выдам свое субъективное мнение о документе (может совершенно не отражать действительность): разобранные примеры очень напоминают по стилю маркетинговые документы по типу "successful stories", отсюда я делаю вывод, что документ составлен из примеров перехода существующий (старых) решений на новые на базе Cache, за исключением одной истории (оценка независимого эксперта). Т.о. получаем сравнение старой системы с потенциально новым решением... хотя конечно могу и ошибаться ^_^

@ 1.4.08, 17:35, Линуксоид
Кстати, по каким-то причинам, документ пропал с сайта cache. Однако всем желающим могу раздать. Стучитесь в аську пятнадцать ноль восемь шестнадцать семьдесят два пять

@ 1.4.08, 18:46, Lynx
не выдержал критики?
а вообще не пропал, проверь настройки прокси/интернета

@ 1.4.08, 18:57, Линуксоид
Да, точно. Просто несколько человек мне сказали что не могут скачать ??? Я и повелся