|
Ответ разработчика
|
|||
---|---|---|---|
#18+
SergeyAKM А если серьезно, то данный документ просто курам на смех. Но хорошо хоть последнее предложение все объясняет: автор ...среда разработки Delphi хорошо известна IT-специалистами... читать как - "а больше все равно нечего и не знают". С этого и надо было начинать. На счет 2-звенки вот например статья , где приводятся некоторые аргументы которые в рамках полного жизненего цикла ПО более значимы, чем " среда разработки Delphi хорошо известна IT-специалистами ". Может сменить таких специалистов . а может не слушать таких советчиков? Что сказать то хотели, кроме ссылок на статьи, которых масса (сколько авторов - столько и мнений)? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2011, 18:59 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
PanshinKachalov, авторМоя личная точка зрения - обработки больших объемов данных(таких которые система не может обработать за приемлемое время) вообще быть не должно Я бы не стал так говорить. Не должно быть таких систем, которые за приемлемое время не могут обработать большие объемы данных. Хочу спросить знает ли кто как идет обработка телефонных звонков в биллинговых системах? Ведь там ежечасно нужно обрабатывать миллионы записей иначе большие объемы данных. Какое решение приемлемо? Трехзвенка? DBA? Причем режим работы был следующий. Если не будет работать программа, то будете сами вручную сидеть и делать начисления на клиентов так как это реальные деньги бизнеса. Поневоле не будешь рассуждать и брать ... Так что собственно будем использовать в этом случае? А собственно по делу то в чем проблема для трех-звенки в вашем приведенном случае, что это за такая невероятна обработка? Может поделитесь о чем речь? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2011, 19:12 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
SergeyAKM А насчет Delphi было бы интересно узнать вот что: на сколько я знаю за бугром Delphi скорее мертв чем жив. То есть мощного сообщества вокруг этого добра нет. Не скажу про европу, но в USA Delphi (точнее, C++ Builder, но это одно и то же :) вполне себе неплохо поживает. Ниша примерно та же, что и у нас - небольшие (2-10 чел.) софт-компании, "самописки" на предприятиях, разработчики shareware. А их там очень много. "Мощного сообщества", действительно, нет. И "множества каркасов на все случаи жизни" тоже нет. IMHO, в этом и плюс. Delphi устоялся как продукт, цели ясны, задачи определены, проблемы решены... Да, стоит недешево, но быстро окупается. PS: мне лет 10 назад пришлось дорабатывать одну систему на COBOL-е, которая была написана еще лет за 15 до того (VAX, OpenVMS)... Ну так она и до сих пор прекрасно себя чувствует, кто-то ее там развивает. PPS: кстати, "трехзвенка" ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2011, 22:58 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
PanshinЯ бы не стал так говорить. Не должно быть таких систем, которые за приемлемое время не могут обработать большие объемы данных. Хочу спросить знает ли кто как идет обработка телефонных звонков в биллинговых системах? Ведь там ежечасно нужно обрабатывать миллионы записей иначе большие объемы данных. Ну, архитектура биллинг-систем известных мне телекомов - это тихий ужас. Там все очень медленно, не слишком надежно и неимоверно дорого. Собственно, неумение сотовых операторов рассчитывать остаток на счете в процессе разговора - замечательное свидетельство плохой архитектуры. В тех телекомах, чью архитектуру я видел (их, впрочем, не слишком много) - асинхронный сбор данных, загрузка в разные промежуточные БД и расчет средствами БД. Дорого и долго. Я вот решал задачи биллинга с аналогичной нагрузкой и с кучей дополнительных сложностей (типа сложных алгоритмов расчета, глобальным риск-менеджементом по потоку операций и т.п.). На трехзвенке - все получается легко и приятно. Можно ли такое сделать средствами только БД - сильно сомневаюсь. По моему опыту, эффективную трехзвенку просто сложнее сделать. Хорошая архитектура предполагает, что ее разработчик умеет обращаться и с БД, и с AppLayer и понимает, какие задачи где должны быть. Таких архитекторов довольно мало. А остальные так и сваливаются - либо в тотальный ORM либо в двузвенку. И, да, горизонтальное масштабирование БД заметно проще (и на порядке дешевле) делать через applayer. Впрочем, это уже относится к нагруженным системам, явно не относящимся к топику. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2011, 02:26 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
Panshinя спрашивал о решении задачи обработки звонков в реальном времени. Ну, средствами БД реальное время, конечно, не получить. Как бы я делал эту систему (при требованиях по масштабированию до 10M одновременных звонков, например): 1) Персональные данные по счету (это не всегда номер телефона) - в БД. БД шардится по счетам, понятное дело. Стратегия шардинга - решается отдельно, через applayer, конечно (а других возможностей и нет сейчас). 2) При появлении звонка - подгружаем на сервер из AppLayer необходимые данные из БД Тут можно поиграть с кэшированием этих данных и решить, выгоднее использовать кэш БД или что-то внешнее. Ну и поиграть с логикой хранения данных в БД, например, денормализация в блоб может обеспечить чтение всех данных по счету за одно физическое чтение. Сильно зависит от конкретной БД. 3) Обеспечиваем, что бы все операции с конкретным счетом в конкретный момент времени выполнял только один appserver (скорее всего через аналог шардинга, тут есть множество тонкостей). Это нужно для гарантии правильности при одновременных действиях со счетом (типа, во время разговора человек еще и в инете сидит и через него же докидывает денег на счет). 4) В процессе звонка ведем учет изменения счета (да хоть раз в секунду пересчитываем остаток). Тут куча возможных оптимизаций, например, считать, на сколько при текущем тарифе хватит разговора и пересчет делать только по исчерпанию срока. 5) Промежуточные данные - в распределенном дублированном кэше (ну, еще можно в локальный лог на диске писать изменения - для гарантии. Потоковая запись - это быстро). Зависит от заявленных требований по надежности. 6) По окончании звонка - изменяем БД. На вскидку, один сервер приложений стандартного вида (где-то на 3k$) будет держать до 100K одновременных разговоров (если не заводить по треду на разговор. Если заводить - то гораздо, гораздо меньше - но зачем делать глупости). БД - один дешевый шард где-то на 50K одновременных разговоров (если разговор - где-то минута), лимитируется скоростью дисковой подсистемы (и, в конечном счете, скоростью seek и надежностью кэша на запись). Все железо - стоит дешевле, чем лицензия на один Oracle EE :) Лицензии - можно вообще обойтись бесплатными БД. Я бы взял DB2 Express C с поддержкой, это, конечно, каких-то денег стоит, но все равно дешевле, чем покупка старших лицензий с партишонингом и прочими радостями жизни... А, отчеты - конечно, строим по standby базам. Ну, там куча разных стратегий - надо смотреть на конкретные требования. Может, будет выгодно сливать в какую-то общую БД (но вряд ли, разве что откат хороший предлагают). И, разумеется, никакого ORM. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2011, 02:50 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
DPH3Ну, архитектура биллинг-систем известных мне телекомов - это тихий ужас. Там все очень медленно, не слишком надежно и неимоверно дорого. Собственно, неумение сотовых операторов рассчитывать остаток на счете в процессе разговора - замечательное свидетельство плохой архитектуры. ... По моему опыту, эффективную трехзвенку просто сложнее сделать. а зачем что-то делать? Все это можно покрыть, например, за счет молодоженов . А в форумах, важно поправляя пенсне на носу, рассуждать какой крутой биллинг... ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2011, 09:15 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
PanshinKachalov, Опять двадцать пять. Хотя я спрашивал о решении задачи обработки звонков в реальном времени. Но можно говорить и о массиве за 5 лет. Разве вы решаете абсурдна обработка пятилетнего массива или нет? Вы должны это сделать. При такой постановке задача с программистской территории явно склонилась в сторону DBA. Или вы будете писать под эту задачу трехзвенку с клиентом? - Вы умело проигнорировали мой ответ: Kachalov Более подробно о возможном решении задачи в Гугле - партиционирование (partitioning). ... мне кажется более логичным когда задача партиционирования ложится не на СУБД, а на архитектора проекта, который исходя из предполагаемого объема данных и связанных с ними задач осуществляет партиционирование на этапе планирования структуры данных - поясняю: когда требуется обрабатывать большие объемы данных этот вопрос должен быть решен на уровне архитектуры (структуры данных) таким образом чтобы не приходилось обрабатывать больших объемов данных. Когда база данных представляет собой одну таблицу в которую тупо валятся все данные очевидно что в дальнейшем будут проблемы при обработке этих данных (имеющих разную востребованность и актуальность). Разбор данных по таблицам меньшего объема желательно производить еще на этапе занесения данных, либо как вариант осуществлять периодическую процедуру "архивации" (переноса данных с низкой актуальностью в архивные таблицы) и предварительного анализа "архивируемых" данных ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2011, 10:09 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
SergeyAKMЕсли взять например платформу .NET, то она может похвалится достаточно динамично развивающимся C#... А у делфей как?У Дельфей хорошо. По сравнению с "семеркой" Delphi XE - это земля и небо. Вкратце - введены расширения синтаксиса, введены новые интерфейсные и проектные плюшки IDE, введен юникод, дженерики, нехило обновлена стандартная библиотека. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2011, 10:57 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
Kachalov, насколько понимаю, речь всё-таки идёт о том, что объем оперативных данных, требующий обработки - довольно велик Поэтому давайте забудем навечно об огромном массиве за 1-2-5 лет и т.д. (хотя в некоторых случаях и такие периоды используются при оперативных расчетах) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2011, 12:34 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
lockyнасколько понимаю, речь всё-таки идёт о том, что объем оперативных данных, требующий обработки - довольно велик Поэтому давайте забудем навечно об огромном массиве за 1-2-5 лет и т.д. (хотя в некоторых случаях и такие периоды используются при оперативных расчетах) - хорошо, "забыли" про 5-2-1 лет, ну тогда что нам мешает "забыть" и про 6-3-1 мес, и про 30-15-1 дней? Или "забыли" про РФ-губерния-город и т. п. Иначе говоря что мешает оперативно работать с тем объемом данных который реально обработать в приемлемый интервал времени, дробя входящие данные на отдельные таблицы? Усложнив структуру данных вполне можно уменьшить объем данных с которым приходится работать. Обработать данные за 5 лет можно путем обработки 5 таблиц содержащих данные за год :) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2011, 13:23 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
Kachalovlockyнасколько понимаю, речь всё-таки идёт о том, что объем оперативных данных, требующий обработки - довольно велик Поэтому давайте забудем навечно об огромном массиве за 1-2-5 лет и т.д. (хотя в некоторых случаях и такие периоды используются при оперативных расчетах) - хорошо, "забыли" про 5-2-1 лет, ну тогда что нам мешает "забыть" и про 6-3-1 мес, и про 30-15-1 дней? Или "забыли" про РФ-губерния-город и т. п. Иначе говоря что мешает оперативно работать с тем объемом данных который реально обработать в приемлемый интервал времени, дробя входящие данные на отдельные таблицы? Усложнив структуру данных вполне можно уменьшить объем данных с которым приходится работать. Обработать данные за 5 лет можно путем обработки 5 таблиц содержащих данные за год :) Ну, про 6-3-1 месяц нам мешает забыть хотя бы наличие годового-квартального-месячного отчета. Как минимум. Во вторых, задача "работать только с тем объемом данных, который мы можем обработать за указанное время" - немного неправильно поставлена. правильно, с моей т.з. - обработка всего необходимого объема данных должна происходить не более чем за указанное время. Более того, иногда (зачастую) - невозможно усложнить структуру данных, раздробив данные на отдельные таблицы - в силу того что это уже было произведено, но и каждая "дробная" часть сама по себе вельми велика. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2011, 15:20 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
немного не в тему, но предполагаю, что здесь есть гуру реализации сложных запросов... :) как запихать в CASE подзапрос? т.е. SELECT CASE doclist.kodreg WHEN 48 THEN '48' WHEN 62 THEN '62' ELSE 'Not yet known' END AS rjl FROM doclist работает ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2011, 17:26 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
Chopнемного не в тему, но предполагаю, что здесь есть гуру реализации сложных запросов... :) пардонте... разобрался - пытался запихать разнотипные значения... ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2011, 17:33 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
W3571С отметается по идеологическим причинам. :) Мы от неё как раз отказались. озвучте причины пожалуйста? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2011, 23:38 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
Раз уз пошел холивар на тему - где делать бизнес-логику - в БД или в app-слое - вставлю свои 5 коп. Вот текст процедуры оптимальной группировки (ящичных партий в полные паллеты) на языке Progress 4GL. Завидуйте, прогресисты могут решить, кто именно будет отрабатывать их логику - основной процесс клиентского приложения, app-сервер или триггер в БД в любой момент ЖЦ системы. Делается простой настройкой типа строчки в ini-файле. А код будет одинаковым !!! При этом исполнение и оптимизация операций с БД (for each, find first, запись и пр.) работает одинаково, независимо от того, какой брокер запросов это исполняет. Также в текст можно вставлять операции на диалекте sql89. В этом фрагменте их нет, так как SQL-брокер Progress не умеет работать с временными таблицами. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144.
Похоже сделано в мире Foxpro, но это файловая СУБД, и сервер приложений на Foxpro - это как-то ... ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2011, 23:48 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
strizhРаз уз пошел холивар на тему - где делать бизнес-логику - в БД или в app-слое - вставлю свои 5 коп. Вот текст процедуры оптимальной группировки (ящичных партий в полные паллеты) на языке Progress 4GL. В этой процедуре есть кусочуки кода с коментариями, которые, по моему мнению, могут быть кандидатами на выделения в подфункции. Почему их не выделили - ограничение языка или предпочтения? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2011, 10:45 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
warhead2В этой процедуре есть кусочуки кода с коментариями, которые, по моему мнению, могут быть кандидатами на выделения в подфункции. Почему их не выделили - ограничение языка или предпочтения? Предпочтения конкректного программера. И, кстати, из-за предпочтений же процедура сделана циклом, а не с помощью рекурсивных вызовов. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2011, 13:15 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
strizhРаз уз пошел холивар на тему - где делать бизнес-логику - в БД или в app-слое - вставлю свои 5 коп. Вот текст процедуры оптимальной группировки (ящичных партий в полные паллеты) на языке Progress 4GL. Завидуйте, прогресисты могут решить, кто именно будет отрабатывать их логику - основной процесс клиентского приложения, app-сервер или триггер в БД в любой момент ЖЦ системы. Делается простой настройкой типа строчки в ini-файле. А код будет одинаковым !!! 1. Использование идентификаторов с символом "-" и обозначение окончания строки с помощью "." снижает читабельность сего кода. 2. 2 процедуры (текущая и GetPalleteNumber) зависят от существования временной таблицы Result-3 -> высокая связанность кода 3. Сама реализация весьма неоптимальна с точки зрения дублирования кода. Рекурсия бы как раз помогла. Думаю вы привели не самый лучший пример реализации бизнес-логики на СУБД ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2011, 09:47 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
svcoder1. Использование идентификаторов с символом "-" и обозначение окончания строки с помощью "." снижает читабельность сего кода. странно слышать про читабельность от 1С-ника. Хоть не с этого начитайте. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2011, 09:53 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
svcoderДумаю <....> привели не самый лучший пример реализации бизнес-логики на СУБД привели пример на 4GL, который может быть выполнен любым "уровнем", в зависимости от настройки. Вы не совсем поняли суть примера, похоже. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2011, 09:58 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
iscrafmsvcoderДумаю <....> привели не самый лучший пример реализации бизнес-логики на СУБД привели пример на 4GL, который может быть выполнен любым "уровнем", в зависимости от настройки. Вы не совсем поняли суть примера, похоже. Совершенно верно, Искра. Я привел пример кода, который можно исполнить: 1) В триггере для таблицы документов на событие OnModify 2) В клиентском приложении при нажатии на кнопочку формы ... 3) На сервере приложений при запуске по расписанию ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2011, 18:12 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
strizhЯ привел пример кода, который можно исполнить: И везде выполнится одинаково плохо :) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2011, 18:13 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
DPH3Ну, архитектура биллинг-систем известных мне телекомов - это тихий ужас. Там все очень медленно, не слишком надежно и неимоверно дорого. Собственно, неумение сотовых операторов рассчитывать остаток на счете в процессе разговора - замечательное свидетельство плохой архитектуры. В тех телекомах, чью архитектуру я видел (их, впрочем, не слишком много) - асинхронный сбор данных, загрузка в разные промежуточные БД и расчет средствами БД. Дорого и долго. Ой. Это у кого из сотовых операторов такое? DPH3Я вот решал задачи биллинга с аналогичной нагрузкой и с кучей дополнительных сложностей... На сколько миллионов абонентов? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.02.2011, 10:52 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
strizhЯ привел пример кода, который можно исполнить: 1) В триггере для таблицы документов на событие OnModify 2) В клиентском приложении при нажатии на кнопочку формы ... 3) На сервере приложений при запуске по расписаниюИ толку ? Почему то Прогресс не захватил ИТ-мир, а остался экзотикой. Не знаете почему ? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.02.2011, 14:24 |
|
Ответ разработчика
|
|||
---|---|---|---|
#18+
aquinoОй. Это у кого из сотовых операторов такое? Хм. NDA. А что, тебе известны более удачные схемы в реальном телекоме? DPH3Я вот решал задачи биллинга с аналогичной нагрузкой и с кучей дополнительных сложностей... На сколько миллионов абонентов? :)[/quot] По ТЗ - единицы миллионов, тестировали на десять миллионов. Сколько реально набрали на данный момент - не знаю. Но какое значение имеет число абонентов? Количество транзакций в секунду и их сложность - это еще сколь-нибудь существенный показатель (у меня был не телеком). ... |
|||
:
Нравится:
Не нравится:
|
|||
03.02.2011, 15:00 |
|
|
start [/forum/topic.php?fid=33&msg=37083702&tid=1548108]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
59ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
others: | 315ms |
total: | 479ms |
0 / 0 |