tanglir,

Ничего не стали делать, так как и так все довольно быстро. 530 т. л/с с 11 услугами на каждом за 2 часа. Это средняя область в РФ по количеству л/с.
Оставили как есть, на будущее.
При тестах был MySql
При тестировании на MariaDB скорость чтения примерно на 16% быстрее.

Dimitry SibiryakovpafesПри тестах был MySql
А... Ню-ню.

И что ню-ню?

Dimitry SibiryakovpafesИ что ню-ню?
Всё ясно с вами.


Так что ясно то? Не уходите от вопроса, иначе это как интрига выглядет. А нас вы тем более не знаете, чтоб вам все с нами ясно было.

Dimitry SibiryakovpafesТак что ясно то?
Что вы попали в мейнстрим: облажались на говноподелке по имени MySQL и начали изобретать
свою собственную. Так сейчас делают все кому не лень.

Если учесть, что оно работает со всеми СУБД и не только с "Реляционными", то нужно подумать... кто тут облажался!

Dimitry SibiryakovpafesЕсли учесть, что оно работает со всеми СУБД и не только с "Реляционными"

Можете продемонстрировать как оно работает с Оракулом?


При необходимости собрать систему с Оракулом, конечно продемонстрируем. Только надо ли оно?
После некоторых событий всем приспичило PostgreSql либо что то СПО, лишь бы работало без сбоев
А вы кроме Оракула ни чего не понимаете? Там драйвер к БД нужно поправить и все. Сейчас только стандартные Sql запросы сделаны в драйвере к реляционным БД (видно на схеме организации ЦОД на 3 стр. темы).

Если интересно будет попробовать то, вам с нашим Тех. Директором нужно пообщаться по поводу
API для работы с драйверами и интерфейсом.

Dimitry SibiryakovАга, так вот какое у вас там "работает со всеми СУБД"... Всего-то "надо драйвер поправить"...


Да, и может одновременно с несколькими разными работать, какая удобнее под задачу.

Infernal V. RavenpafesПри необходимости собрать систему с Оракулом, конечно продемонстрируем. Только надо ли оно?Мне это в первую очередь говорит о том, что специфика СУБД не учитывается, а это значит, что вы пытаетесь сделать универсальное решение. Но на практике, универсальные решения имеют свою цену, в данном случае снижающуюся производительность. Отсюда логично предположить, что в "мы реально уперлись в скорость чтения БД, при начислениях" виновата не СУБД, а архитектура вашего приложения. Как пример неподходящей архитектуры для биллинга - 1С, они тоже большим количеством запросов, там где это не следует делать, могут вызвать такие же симптомы, при этом на учетных задачах это совершенно некритично.

Мы раньше писали, что на данный момент применяются стандартные Sql запросы, что позволяет не привязываться к вендору СУБД.
Но так же писали, что увеличение производительности оставили на потом, так как это на данный момент не критично. Так как производительность в настоящее время на 10 баллов, по сравнению с решениями конкурентов.

Для сравнения:
Город 60 000 л/с, только лишь формирование квитанций на оплату,считается за 2 часа. А все остальные перерасчёты и закрытие месяца за 6 часов. Итого примерно 8 часов.
При чем система начислений не имеет личного кабинета, приема платежей, сбора показаний приборов учета, формирования программ капитального ремонта, электронного паспорта дома и прочего... И занимает первое место среди внедренных городских систем по Московской области в 2012 году.

Infernal V. RavenpafesМы раньше писали, что на данный момент применяются стандартные Sql запросы, что позволяет не привязываться к вендору СУБД.Биллинг ЖКХ - узкоспециализированная задача. Поэтому делать СУБД-независимое решение, на мой взгляд, не стоит. По-возможности, нужно делать как раз наоборот - переносить все обработки на СУБД. Иначе опять получается в лучшем случае биллинг среднего сегмента, который не справляется со сколько либо серьезными объемами. Это с технической точки зрения. Из этого также вытекает, что для мелких УО он также не нужен, потому что для них дорог.
pafesНо так же писали, что увеличение производительности оставили на потом, так как это на данный момент не критично. Т.е. это уже в архитектуру заложено. Собственно вариантов по оптимизации, вероятно, будет не так много - индексы, партиционирование. А на крайний случай - отказ от СУБД-независимости и уход к СУБД.

pafesДля сравнения:
Город 60 000 л/с, только лишь формирование квитанций на оплату,считается за 2 часа. А все остальные перерасчёты и закрытие месяца за 6 часов. Итого примерно 8 часов.
При чем система начислений не имеет личного кабинета, приема платежей, сбора показаний приборов учета, формирования программ капитального ремонта, электронного паспорта дома и прочего... И занимает первое место среди внедренных городских систем по Московской области в 2012 году.Мегаполис что-ли? Ну да неважно. Для бизнеса это важно, сколько времени расчет идет? На практике на таких объемах, даже если два дня считать будет - это некритично, но технически конечно некрасиво, да.
Там выше, на странице, есть приведение тестов нашей системы по производительности. 530 т. л/с в полном объеме за 2 часа.
На железе стоимостью до 120т.р.

В ЖКХ период заканчивается 26 числа, а 1 нужно квитанции разнести. Так что при создании расчетных центров области (500т. л/с средний регион в РФ), 2 часа само по себе снимает какую либо проблему с начислениями. А бухгалтеров нужно всего 3 человека на область, чтоб хозяйственную деятельность свести. И прозрачность полная.

Infernal V. RavenСмотря что и как считать. Например льготы, выпадающие доходы (особенно) могут сурово изменить ситуацию.

Правила взаиморасчетов и оказания услуг ЖКХ, четко расписаны в ПП№354, и в прочих связывающих законах. Самодеятельность в УК до сих пор процветает, порой за счет того, что УК работают на устаревшем софте. Это ПО не может осуществлять правильно взаиморасчеты, так как структура БД не позволяет это сделать. Переписывать это старое ПО невозможно, а писать новое мало кто стал, а если кто и стал ... то года 4 пройдет пока его доведут до ума. А современный сервис нужен людям уже сейчас.

Infernal V. RavenТак далеко не везде. :)

Так однако, должно быть, а если не так... то прямой путь в прокуратуру. Так как это говорит о не выполнении постановления ПП №354,

V&Nобчём топик?
нифига не понял ... oracle/mysql/... - фигня. все тормозят на select/insert/update/delete ...
поэтому написали свою прослойку, которая не тормозит, но данные хранит в oracle/mysql/....
парадокс.

Совершенно верно!
Одна из целей, была не тормозящая прослойка.
Другая цель, объединить удобные функции реляционных и не реляционных баз данных. Это позволило расширить функции Веб интерфейса, и упростить их разработку.
Третья реализованная цель, снизить трафик. Система позволяет отлично работать при 128kb., что актуально там где пользуются мобильным Интернет.