Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7   вперед  Ctrl      все
 Re: Российские СУБД  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28355
pafes, раскройте смысл этой фразы: "мы реально уперлись в скорость чтения БД, при начислениях".
13 ноя 14, 16:41    [16841569]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54798

skyANA
раскройте смысл этой фразы: "мы реально уперлись в скорость чтения БД, при
начислениях".

Вангую: был у них Оракул и он не смог выполнить update clients set balance=balance*1.001
на каких-нибудь двадцати миллионах записей.

Posted via ActualForum NNTP Server 1.5

13 ноя 14, 16:50    [16841665]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
tanglir
Member

Откуда:
Сообщений: 28966
Dimitry Sibiryakov
skyANA
раскройте смысл этой фразы: "мы реально уперлись в скорость чтения БД, при
начислениях".

Вангую: был у них Оракул и он не смог выполнить update clients set balance=balance*1.001
на каких-нибудь двадцати миллионах записей.
а мне интересно, что они сделали, чтобы переставать "упираться"
перестали читать из базы?
14 ноя 14, 05:56    [16843743]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
pafes
Member

Откуда:
Сообщений: 36
tanglir,

Ничего не стали делать, так как и так все довольно быстро. 530 т. л/с с 11 услугами на каждом за 2 часа. Это средняя область в РФ по количеству л/с.
Оставили как есть, на будущее.
При тестах был MySql
При тестировании на MariaDB скорость чтения примерно на 16% быстрее.
15 ноя 14, 18:38    [16851934]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54798

pafes
При тестах был MySql

А... Ню-ню.

Posted via ActualForum NNTP Server 1.5

15 ноя 14, 18:48    [16851953]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
pafes
Member

Откуда:
Сообщений: 36
Dimitry Sibiryakov
pafes
При тестах был MySql

А... Ню-ню.

И что ню-ню?
15 ноя 14, 22:51    [16852459]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54798

pafes
И что ню-ню?

Всё ясно с вами.

Posted via ActualForum NNTP Server 1.5

15 ноя 14, 22:58    [16852481]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
pafes
Member

Откуда:
Сообщений: 36
Dimitry Sibiryakov
pafes
И что ню-ню?

Всё ясно с вами.


Так что ясно то? Не уходите от вопроса, иначе это как интрига выглядет. А нас вы тем более не знаете, чтоб вам все с нами ясно было.
16 ноя 14, 12:43    [16853378]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54798

pafes
Так что ясно то?

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

Posted via ActualForum NNTP Server 1.5

16 ноя 14, 12:47    [16853391]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
pafes
Member

Откуда:
Сообщений: 36
Dimitry Sibiryakov
pafes
Так что ясно то?

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

Если учесть, что оно работает со всеми СУБД и не только с "Реляционными", то нужно подумать... кто тут облажался!
16 ноя 14, 17:58    [16854452]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54798

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

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

Posted via ActualForum NNTP Server 1.5

16 ноя 14, 18:08    [16854496]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
pafes
Member

Откуда:
Сообщений: 36
Dimitry Sibiryakov
pafes
Если учесть, что оно работает со всеми СУБД и не только с "Реляционными"

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


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

Если интересно будет попробовать то, вам с нашим Тех. Директором нужно пообщаться по поводу
API для работы с драйверами и интерфейсом.
16 ноя 14, 22:42    [16855403]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54798

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

Posted via ActualForum NNTP Server 1.5

16 ноя 14, 22:50    [16855441]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
pafes
Member

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


Да, и может одновременно с несколькими разными работать, какая удобнее под задачу.
17 ноя 14, 00:08    [16855739]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
sphinx_mv
Member [заблокирован]

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


Да, и может одновременно с несколькими разными работать, какая удобнее под задачу.
Шапкозакидательство - это, типа, национальная черта характера такая?
Вот когда "драйвер подправите", тогда и будет работать "со всеми"... Не говоря уже про ""одновременно...
17 ноя 14, 01:11    [16855902]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Infernal V. Raven
Member

Откуда: St.Petersburg
Сообщений: 1710
pafes
При необходимости собрать систему с Оракулом, конечно продемонстрируем. Только надо ли оно?
Мне это в первую очередь говорит о том, что специфика СУБД не учитывается, а это значит, что вы пытаетесь сделать универсальное решение. Но на практике, универсальные решения имеют свою цену, в данном случае снижающуюся производительность. Отсюда логично предположить, что в "мы реально уперлись в скорость чтения БД, при начислениях" виновата не СУБД, а архитектура вашего приложения. Как пример неподходящей архитектуры для биллинга - 1С, они тоже большим количеством запросов, там где это не следует делать, могут вызвать такие же симптомы, при этом на учетных задачах это совершенно некритично.
17 ноя 14, 11:28    [16857199]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
pafes
Member

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


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

Для сравнения:
Город 60 000 л/с, только лишь формирование квитанций на оплату,считается за 2 часа. А все остальные перерасчёты и закрытие месяца за 6 часов. Итого примерно 8 часов.
При чем система начислений не имеет личного кабинета, приема платежей, сбора показаний приборов учета, формирования программ капитального ремонта, электронного паспорта дома и прочего... И занимает первое место среди внедренных городских систем по Московской области в 2012 году.
18 ноя 14, 16:26    [16866496]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Infernal V. Raven
Member

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

pafes
Для сравнения:
Город 60 000 л/с, только лишь формирование квитанций на оплату,считается за 2 часа. А все остальные перерасчёты и закрытие месяца за 6 часов. Итого примерно 8 часов.
При чем система начислений не имеет личного кабинета, приема платежей, сбора показаний приборов учета, формирования программ капитального ремонта, электронного паспорта дома и прочего... И занимает первое место среди внедренных городских систем по Московской области в 2012 году.
Мегаполис что-ли? Ну да неважно. Для бизнеса это важно, сколько времени расчет идет? На практике на таких объемах, даже если два дня считать будет - это некритично, но технически конечно некрасиво, да.
18 ноя 14, 19:05    [16867776]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
pafes
Member

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

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

Там выше, на странице, есть приведение тестов нашей системы по производительности. 530 т. л/с в полном объеме за 2 часа.
На железе стоимостью до 120т.р.

В ЖКХ период заканчивается 26 числа, а 1 нужно квитанции разнести. Так что при создании расчетных центров области (500т. л/с средний регион в РФ), 2 часа само по себе снимает какую либо проблему с начислениями. А бухгалтеров нужно всего 3 человека на область, чтоб хозяйственную деятельность свести. И прозрачность полная.
18 ноя 14, 20:43    [16868288]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Infernal V. Raven
Member

Откуда: St.Petersburg
Сообщений: 1710
pafes
Там выше, на странице, есть приведение тестов нашей системы по производительности. 530 т. л/с в полном объеме за 2 часа.
На железе стоимостью до 120т.р.
Смотря что и как считать. Например льготы, выпадающие доходы (особенно) могут сурово изменить ситуацию.
pafes
В ЖКХ период заканчивается 26 числа, а 1 нужно квитанции разнести.
Так далеко не везде. :)
20 ноя 14, 09:56    [16876319]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
pafes
Member

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


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

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


Так однако, должно быть, а если не так... то прямой путь в прокуратуру. Так как это говорит о не выполнении постановления ПП №354,
20 ноя 14, 10:26    [16876522]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Infernal V. Raven
Member

Откуда: St.Petersburg
Сообщений: 1710
pafes
Правила взаиморасчетов и оказания услуг ЖКХ, четко расписаны в ПП№354, и в прочих связывающих законах.

Не будьте наивным. ФЗ утверждает основной порядок. Регионы могут додумывать остальные правила, которые не противоречат федеральным. При этом весьма хитро придумывать.
pafes
Самодеятельность в УК до сих пор процветает, порой за счет того, что УК работают на устаревшем софте. Это ПО не может осуществлять правильно взаиморасчеты, так как структура БД не позволяет это сделать.
Софт тут не при чем. И уж тем более не нужно делать из него причину.
pafes
Переписывать это старое ПО невозможно, а писать новое мало кто стал, а если кто и стал ... то года 4 пройдет пока его доведут до ума. А современный сервис нужен людям уже сейчас.
Смотря какого масштаба софт. Его много уже написано да и новый написать, даже для больших субъектов - возможно, было бы финансирование. Финансирование происходит в рамках региональных бюджетов, а на федеральном уровне финансируют только Ростелеком и почту. На региональном уровне обычно создается специализированный продукт, отвечающий региональным требованиям, дальнейшее его распространение не происходит.

Что у вас? Кого автоматизировали-то? Какие субъекты?
20 ноя 14, 11:15    [16876913]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
V&N
Guest
обчём топик?
нифига не понял ... oracle/mysql/... - фигня. все тормозят на select/insert/update/delete ...
поэтому написали свою прослойку, которая не тормозит, но данные хранит в oracle/mysql/....
парадокс.
20 ноя 14, 15:20    [16879246]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
pafes
Member

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


Совершенно верно!
Одна из целей, была не тормозящая прослойка.
Другая цель, объединить удобные функции реляционных и не реляционных баз данных. Это позволило расширить функции Веб интерфейса, и упростить их разработку.
Третья реализованная цель, снизить трафик. Система позволяет отлично работать при 128kb., что актуально там где пользуются мобильным Интернет.
20 ноя 14, 17:27    [16880423]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
lLocust
Member

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


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


Подождите...
Вы написали СУБД-независимый толстый клиент. Может быть ORM. И все. Молодцы. Но нет никакого отношения ни то что к теме топика, даже к разделу форума!
А Ваша "ненавязчивая" реклама на данном форуме приводит к обратному (рекламе) эффекту. Будь я консультантом при выборе ИС я бы раз 10 подумал прежде чем ее выбрать. (И то, только если у Ваших конкурентов полный тухляк)
20 ноя 14, 19:35    [16881292]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить