В каждом случае все равно показатели индивидуальны. Что сделано в нашем случае мы описали в статьях:
https://habrahabr.ru/company/ultima/blog/255081/
https://habrahabr.ru/company/ultima/blog/255685/
Тексты правда немного устарели — выяснилось, что прямой опрос дает искаженную (как правило завышенную) оценку, не отражающую реального положения вещей. Поэтому сейчас мы экспериментируем с альтернативными вариантами, по результатам постараемся отписаться в течние нескольких месяцев.
Собственно, подавляющее большинство подразделений в компании-клиенте, где внедряется наша система подчиняются всем этим правилам. Это же верно и для нашей собственной компании.
Я правильно понимаю, что вы еще неявно предполагаете, что выполнение запроса практически бесплатно? Имею ввиду что несколько раз выполнить запрос не отличается от выполнить запрос один раз и зачитать все данные.
удивительная "средняя асимптотическая сложность". При идеальной реализации хещ-функции (сложность вычисления которой тоже не ноль) в среднем, для поиска элемента потребуется константное число операций.
Однако, асимптотическая сложность O(logN) потому как я МОГУ поддерживать список сортированным и для этого достаточно логарифма.
еще при первом знакомстве с абаперами понял, что гвозди бы делать из этих людей.
Такие простыни кода для такого результата вообще никого не удивляют и не расстраивают.
Пользователи, кстати, тоже оказываются в условиях безысходности способны на чудеса запоминания невнятных аббревиатур и кодов.
Минимумы описаны подробно тут (для Windows) docs.oracle.com/database/121/NTDBI/reqs.htm#NTDBI2692
и тут для Linux docs.oracle.com/database/121/LADBI/pre_install.htm#LADBI7498
Для Windows x64 инсталляции Physical memory (RAM) 4 GB minimum.
Для Linux 1Gb. При этом, оракл рекомендует (без всяких предусловий) 2Гб.
В нашем сервере для Ultima Cloud мы исходили из типовой нагрузки для 12 пользователей (точнее — типовой нагрузки 12 пользователей с учетом нагрузки с сайта) и там выдается 4Гб (Сервер там под Linux, конечно). Это мы даже с запасом взяли.
Память в оракле (да и любой другой базе) используется преимущественно как кэш. Так что малый объем памяти будет приводить только к избыточному использованию диска и соответственно снижению производительности системы.
При небольшой транзакционной нагрузке это отражается только на интерактивности пользовательского интерфейса, и это можно терпеть. Хуже, если нагрузка большая (например с сайта очень активно ставят заказы, особенно на маленьком прайслисте — активная торговля ядерными реакторами) в этом случае увеличение времени выполнения транзакции может приводить к преждевременному взрывному росту блокировок. Но, думаю, для этого на базе даже с 2Гб памяти надо уйти за уровень 50 заказов и отгрузок в час. Если у вас столько заказов, то обычно можно себе позволить и больше сервера.
Но к счастью, это все не является такой уж проблемой :)
Ибо оракл лицензируется по процессорным ядрам а не по размеру памяти. Так что вы можете взять «нормальный» сервер и установить на нем оракл на виртуальную машину с одним процессорным ядром. Нормальная виртуализация при этом будет давать незначительный оверхед (если использовать KVM или HyperZ).
12.1.0.2 linux x64
Извините, но искать номера довольно муторно и главное, вы вряд ли их можете как-то пропихнуть к исправлению, а мы уже нашли workaround. Так что сорри, но мне лень искать, реквесты создали до нас.
Должен извинится — одна исправилась 5-го октября вышел новый релиз ODAC с ODP.NET где исправлена ошибка с загрузкой CLOB в x86 конфигурации.
Остальные — остались. В нашем случае это 3 запроса, валяшихся с ORA-600. Их уже переформулировали и смогли обойти. На 11g они работают.
Когда мы переходили на 11g проблем было меньше.
https://habrahabr.ru/company/ultima/blog/255081/
https://habrahabr.ru/company/ultima/blog/255685/
Тексты правда немного устарели — выяснилось, что прямой опрос дает искаженную (как правило завышенную) оценку, не отражающую реального положения вещей. Поэтому сейчас мы экспериментируем с альтернативными вариантами, по результатам постараемся отписаться в течние нескольких месяцев.
Если у Вас не получается, возможно что-то надо изменить в подходе?
Систему для разработчиков я выкладывал.
Про какое несуществующее решение речь?
Однако, асимптотическая сложность O(logN) потому как я МОГУ поддерживать список сортированным и для этого достаточно логарифма.
На самом деле там O(NlogM) где M — меньший список. Это про hash-join
Такие простыни кода для такого результата вообще никого не удивляют и не расстраивают.
Пользователи, кстати, тоже оказываются в условиях безысходности способны на чудеса запоминания невнятных аббревиатур и кодов.
и тут для Linux docs.oracle.com/database/121/LADBI/pre_install.htm#LADBI7498
Для Windows x64 инсталляции Physical memory (RAM) 4 GB minimum.
Для Linux 1Gb. При этом, оракл рекомендует (без всяких предусловий) 2Гб.
В нашем сервере для Ultima Cloud мы исходили из типовой нагрузки для 12 пользователей (точнее — типовой нагрузки 12 пользователей с учетом нагрузки с сайта) и там выдается 4Гб (Сервер там под Linux, конечно). Это мы даже с запасом взяли.
Память в оракле (да и любой другой базе) используется преимущественно как кэш. Так что малый объем памяти будет приводить только к избыточному использованию диска и соответственно снижению производительности системы.
При небольшой транзакционной нагрузке это отражается только на интерактивности пользовательского интерфейса, и это можно терпеть. Хуже, если нагрузка большая (например с сайта очень активно ставят заказы, особенно на маленьком прайслисте — активная торговля ядерными реакторами) в этом случае увеличение времени выполнения транзакции может приводить к преждевременному взрывному росту блокировок. Но, думаю, для этого на базе даже с 2Гб памяти надо уйти за уровень 50 заказов и отгрузок в час. Если у вас столько заказов, то обычно можно себе позволить и больше сервера.
Но к счастью, это все не является такой уж проблемой :)
Ибо оракл лицензируется по процессорным ядрам а не по размеру памяти. Так что вы можете взять «нормальный» сервер и установить на нем оракл на виртуальную машину с одним процессорным ядром. Нормальная виртуализация при этом будет давать незначительный оверхед (если использовать KVM или HyperZ).
Извините, но искать номера довольно муторно и главное, вы вряд ли их можете как-то пропихнуть к исправлению, а мы уже нашли workaround. Так что сорри, но мне лень искать, реквесты создали до нас.
Должен извинится — одна исправилась 5-го октября вышел новый релиз ODAC с ODP.NET где исправлена ошибка с загрузкой CLOB в x86 конфигурации.
Остальные — остались. В нашем случае это 3 запроса, валяшихся с ORA-600. Их уже переформулировали и смогли обойти. На 11g они работают.
Когда мы переходили на 11g проблем было меньше.