Comments 8
Решение может и интересное, но из-за стоимости владения (Oracle DB, оборудование под него) очень имхо нишевое. Оракл конечно относительно быстр, но вот вопрос с количеством входящих данных и хранящимися данными могут встать очень остро (200 сообщений в секунду это вобще мелочь, а у вас уже вроде все ложится). А покупать экзадату для обработчика логов будет смотреться очень странно. Т.е. реально ощущение «у нас суровый энтерпрайз, мы можем немного подвинуть ораклевую лицензию, давайте пилить на нем»
Выбрали Oracle потому, что делаем промышленное решение — у нас отличная поддержка данной СУБД. Сейчас вся БД работает на одной виртуальной машине (KVM) под управлением Red Hat Linux. На ней всего 4 CPU и 12RAM. Прежде чем закидывать продукт «железом», мы стараемся сперва провести все возможные оптимизации внутри системы.
Работы в этом направлении еще много :)
Работы в этом направлении еще много :)
Вот в свое время мы напоролись на тему с виртуализированным ораклом. У него очень оригинальная модель лицензирования для Oracle DB Enterprise в виртуальном окружении. Они признают только свою виртуализацию на своем железе. Т.е. только на их железе ты можешь выделить например 4 vCPU и их оплатить. На чужой виртуализации нужно лицензировать весь хост целиком (все ядра на всех процах) и чуть ли не умножить на сумму всех виртуалок с ораклом. А если не дай бог у тебя еще кластер виртуализации — помножь на все хосты в кластере. При стоимости 45000$ за одно физическое ядро — получается космический корабль. Обычно разработчики об этом не задумываются когда подбирают инструмент (как в принципе получилось у нас), а вот когда вскрывается — становится очень неприятно.
Сперва мы изобрели «велосипед» и сделали таблицу MUTEX, которую блокировали на доли секунды на время расчета значения счетчика. Под большой нагрузкой стали ловить dead block. Потом воспользовались пакетом DBMS_LOCK и создали блокировку куска кода, который работал со счетчиком.
вообще существуют оптимистические блокировки и конструкции типа:
UPDATE counters SET value = value + 1 WHERE name = :name AND value := old_valueну и в 21м веке уже есть in-memory решения которые делают такое мгновенно, атомарно и с персистентностью
Можно было воспользоваться оптимистической блокировкой, но со строкой для конкретного запуска происходит много UPDATE за короткий промежуток времени, т.е. одну и ту же транзакцию, возможно, придется повторить многократно. Оптимистические блокировки больше подходят в том случае, если при пессимистической блокировке пришлось бы блокировать тяжелые длительные операции.
У нас же UPDATE всего одной строки в небольшой таблице, поэтому большого смысла применять данный тип блокировки не было. Ради интереса можно провести эксперимент, как будет попробуем такой тест и расскажем о результатах.
Отвечая на комментарий про in-memory решения: у нас уже была идея отказаться от очередей AQ, воспользоваться in-memory для хранения и обработки шинглов. Многих проблем можно было бы избежать, используя 12g (сейчас все работает под 11g). Вопрос в проработке, спасибо за комментарий!
У нас же UPDATE всего одной строки в небольшой таблице, поэтому большого смысла применять данный тип блокировки не было. Ради интереса можно провести эксперимент, как будет попробуем такой тест и расскажем о результатах.
Отвечая на комментарий про in-memory решения: у нас уже была идея отказаться от очередей AQ, воспользоваться in-memory для хранения и обработки шинглов. Многих проблем можно было бы избежать, используя 12g (сейчас все работает под 11g). Вопрос в проработке, спасибо за комментарий!
Тут скорее вопрос в том, для чего именно нужен реалтайм счетчик, может быть можно использовать sequence для генерации id и дополнительный запрос для вычисления количества сообщений?
Спасибо за вопрос!
Реалтайм счетчики нужны для сопоставления количества пришедших сообщений ожидаемому количеству для определенного запуска, конкретной системы и тестового стенда. Ожидаемое количество сообщений для запуска попадает в таблицу через отдельный сервис.
Счетчики — уникальны для каждого запуска, а запуски идут параллельно, поэтому пришлось бы делать свой sequence для каждого запуска автотестов.
Некоторые сообщения из-за нарушения протокола могут оказаться некорректными и не попасть в целевую таблицу после обработки очереди, поэтому доп. запрос для вычисления количества сообщений так же не подойдет.
Реалтайм счетчики нужны для сопоставления количества пришедших сообщений ожидаемому количеству для определенного запуска, конкретной системы и тестового стенда. Ожидаемое количество сообщений для запуска попадает в таблицу через отдельный сервис.
Счетчики — уникальны для каждого запуска, а запуски идут параллельно, поэтому пришлось бы делать свой sequence для каждого запуска автотестов.
Некоторые сообщения из-за нарушения протокола могут оказаться некорректными и не попасть в целевую таблицу после обработки очереди, поэтому доп. запрос для вычисления количества сообщений так же не подойдет.
Сейчас мы прорабатываем создание нового механизма. При успешном окончании обработки сущности шага, будет дополнительно осуществляется вставка в таблицу X идентификатора запуска обработанного шага. Соответственно, зная общее кол-во шагов в тесте, мы сможем сравнить это кол-во с кол-вом записей в таблице X, если они равны — значит загрузка была завершена в полном объеме. После этого мы можем приступать к следующему шагу обработки результатов, заодно почистив эту таблицу.
Предполагаем, что подобная реализация позволит нам уйти от блокировок и реалтайм счетчиков, заодно повысив производительность решения.
Давайте обсуждать идею, будем рады обратной связи!
Предполагаем, что подобная реализация позволит нам уйти от блокировок и реалтайм счетчиков, заодно повысив производительность решения.
Давайте обсуждать идею, будем рады обратной связи!
Sign up to leave a comment.
Не трогайте логи руками. Часть 2: как мы внедряли Unified Logfile Analyser