По моим измерениям те же 0.5с на отдачу страницы.
Предлагаю закончить фехтование линейками и писюнами. Модель EAV достаточна для 99% интернет-магазинов рунета, удобна в поддержка и обладает многими преимуществами структурированности данных. Никто не спорит, что есть случаи, когда EAV не позволит выполнить требования. Ни EAV, ни другие решения не являются догмами, и ВСЕ имеют свои плюсы и минусы и области применения.
текущую версию делали не мы. И даже при этом, я могу сказать что тормозит скорее клиентская часть.
На нашем движке страницы отдавались не более чем за 0.5с
потому, что подавляющее большинство приложений не ожидают никаких откатов при выполнении commit — один из ответов.
Правда есть есть deffered constraints которые могут commit отменить.
Про все это уже в металинке и форумах 1000 раз обсуждено, но события нет.
Либо придется весь объем данных для передачи «наружу» передавать в параметрах для джоба, что не уменьшает нагрузку на диск, либо передавать их сразу, но тогда надо знать — закончилась транзакция или нет, чтобы пометить переданные в триггере данные как закомиченные или удалить.
Абсолютно согласен. Хотя латчи самого оракла такое иногда вытворяют… и нагрузка на редологи только увеличивает вероятность.
Короче, опасности везде поджидают )
Тяжеловесно :) Так же как делать триггер на materialized view которая OnCommit обновляется.
И не решает проблемы обработки Rollback. Я этой задачей интересовался в попытках реализовать хранение логов изменений данных в NoSQL DB. Собственно я хотел избежать дополнительных записей в таблицы и иметь актуальные данные. При наличии обработки коммита можно только частично решить задачу.
Не совсем так. OCN построена поверх Advanced Queue которые, в свою очередь построены на обычных таблицах.
Так что производительность триггеров, которые пишут в сокет будет скорее всего ВЫШЕ чем при использовании OCN (у которого будут писаться редо логи, архив логи, undo segment и т.п.)
Проблема с триггерами и записью в сокет в том, что в оракле нет события (триггера) OnCommit, на которое можно было бы повесить обработчик (само событие вообще-то есть — materialized view умеют по OnCommit обновлятся).
Я даже где-то понимаю оракловцев мужественно терпящих висящий с 90-х годов тикет про это событие. Действительно — а что делать если в обработчике произошло исключение? делать роллбек? или все-таки коммит?
Так вот, в триггере на таблице, который пишет в сокет проблема в том, что вы не можете определить достоверность данных. Т.е. можно реализовать идиотский метод — запрашивать данные «в обратку» но тогда вы нагрузите оракл лишними запросами и достоверность не увеличите. Вы же не знаете, закончилась транзакция или нет.
Мы намаялись с этим классом так, что в итоге написали свою версию.
У DataTable кроме того, что он невероятно тяжеловесный в памяти, еще и при сериализации распухает невероятно. Время сериализации-десериализации ужасное. Для целей получить табличку-пробежать по строчкам (что и должно происходить при наличии БД) этой ИМХО лучший вариант. Если задачи еще какие-то, то может подумать о БД? Там все равно работа с большими таблицами лучше организована чем в DataTable.
Удивительные результаты!
В первых экспериментах на поиск время растет логарифмически, это я еще могу как-то понять. Но в последнем эксперименте такое поведение уже совсем не укладывается в голове.
Кстати, а как выглядела схема для MySQL? Были ли индексы, какие запросы выполнялись?
У Вас есть свое предположение о причинах такого роста времени у Neo4j?
Это да. Я не знаю, какая система у Вас, но может еще стоило написать, что такой сервис должен блокировочку ставить чтобы избежать попытки одновременного доступа из нескольких потоков.
Предлагаю закончить фехтование линейками и писюнами. Модель EAV достаточна для 99% интернет-магазинов рунета, удобна в поддержка и обладает многими преимуществами структурированности данных. Никто не спорит, что есть случаи, когда EAV не позволит выполнить требования. Ни EAV, ни другие решения не являются догмами, и ВСЕ имеют свои плюсы и минусы и области применения.
На нашем движке страницы отдавались не более чем за 0.5с
А у вас опять много громких заявлений.
Конкретно — ulmart.ru его предыдущий дизайн сайта.
Правда есть есть deffered constraints которые могут commit отменить.
Про все это уже в металинке и форумах 1000 раз обсуждено, но события нет.
Короче, опасности везде поджидают )
И не решает проблемы обработки Rollback. Я этой задачей интересовался в попытках реализовать хранение логов изменений данных в NoSQL DB. Собственно я хотел избежать дополнительных записей в таблицы и иметь актуальные данные. При наличии обработки коммита можно только частично решить задачу.
Так что производительность триггеров, которые пишут в сокет будет скорее всего ВЫШЕ чем при использовании OCN (у которого будут писаться редо логи, архив логи, undo segment и т.п.)
Проблема с триггерами и записью в сокет в том, что в оракле нет события (триггера) OnCommit, на которое можно было бы повесить обработчик (само событие вообще-то есть — materialized view умеют по OnCommit обновлятся).
Я даже где-то понимаю оракловцев мужественно терпящих висящий с 90-х годов тикет про это событие. Действительно — а что делать если в обработчике произошло исключение? делать роллбек? или все-таки коммит?
Так вот, в триггере на таблице, который пишет в сокет проблема в том, что вы не можете определить достоверность данных. Т.е. можно реализовать идиотский метод — запрашивать данные «в обратку» но тогда вы нагрузите оракл лишними запросами и достоверность не увеличите. Вы же не знаете, закончилась транзакция или нет.
У DataTable кроме того, что он невероятно тяжеловесный в памяти, еще и при сериализации распухает невероятно. Время сериализации-десериализации ужасное. Для целей получить табличку-пробежать по строчкам (что и должно происходить при наличии БД) этой ИМХО лучший вариант. Если задачи еще какие-то, то может подумать о БД? Там все равно работа с большими таблицами лучше организована чем в DataTable.
В первых экспериментах на поиск время растет логарифмически, это я еще могу как-то понять. Но в последнем эксперименте такое поведение уже совсем не укладывается в голове.
Кстати, а как выглядела схема для MySQL? Были ли индексы, какие запросы выполнялись?
У Вас есть свое предположение о причинах такого роста времени у Neo4j?
С тех пор проще и дешевле реализовать работу с SMS через гейты SMPP протоколом.