|
|
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
Пишу автоматизированную систему обработки данных. На удаленном сервере стоит виртуальная машина с OpenSuse (Linux), на ней стоит база данных MySQL, в которую сваливаются "сырые" данные. На параллельной виртуальной машине стоит Windows, на котором работает мой расчетный модуль, написанный на Delphi. По мере поступления свежих данных в базу расчетный модуль эти данные берёт, обрабатывает, и результат обработки складывает обратно в базу. По истечении года развития Дельфи-проект стал чересчур тяжеловесным и не очень надежным - слишком много в нем пересекается логики, слишком много идей, о которых было неизвестно с самого начала, нашлепывалось по ходу дела. Теперь процесс обработки данных оптимизируется. И вот пришла мысль, что мой подход вообще неоптимален. Множество элементарных расчетных операций можно было бы делать мелкими модулями, каждый из которых отвечал бы за небольшую часть: берет конкретные данные из MySQL, обрабатывает их и складывает результат обратно в MySQL , остальное - не его дело. Плюс к этому, хотелось бы иметь гибкость в редактировании алгоритмов обработки без необходимости постоянно компилировать исполняемый модуль - то есть некая скриптовость. И вот думается: а зачем реализовывать это все на дельфи, если и без того существуют интерпретируемые скриптовые языки программирования типа Perl. Представляется такая схема - некий очередной скрипт пишется, хранится в той же базе, активизируется юзером когда нужно, и выполняет свою часть вычислений. Спрашивается - что бы это могло быть? Perl-интерпретатор, Java, что-то другое? Где его разместить - на той же Linux-машине? С перлом я не знаком, да и с линуксом тоже не особо - скажем, там же тоже надо как-то следить за утечкой памяти, как это случается с моими дельфи-монстрами на виндах? Интересны любые мысли на тему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2010, 20:44:49 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
daybit, Реализуйте всю бизнес-логику на SQL, Вы не поверите, но именно для этого он и существует. Тогда у Вас такой вопрос не появится в принципе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2010, 20:59:18 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
ShSerge, как это сделать? Все расчетные циклы, условия, синусы-косинусы? И как MySQL будет запускать эти расчеты? Какие-то триггеры прихода данных? MySQL это все умеет сам, без нашлепок? До этого я использовал его исключительно в качестве хранилища. ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2010, 21:26:26 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
daybit, Современные базы данных всё это умеют прекрасно делать с помощью SQL. По правде сказать, MySQL этому не так давно научился. Теперь имеются триггеры, х-ые процедуры и функции. Короче, ясен помидор, всю бизнес-логику можно (и нужно!) перенести на уровень БД. Вы удивитесь, насколько просты станут Ваши программы. Типа, написал запрос, написал интерфейс - ура!, работает. Никакой перекомпиляции, если что не так, просто изменяем скрипт... о! работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2010, 21:51:06 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
ShSergedaybit, Современные базы данных всё это умеют прекрасно делать с помощью SQL. По правде сказать, MySQL этому не так давно научился. Теперь имеются триггеры, х-ые процедуры и функции. Короче, ясен помидор, всю бизнес-логику можно (и нужно!) перенести на уровень БД. Вы удивитесь, насколько просты станут Ваши программы. Типа, написал запрос, написал интерфейс - ура!, работает. Никакой перекомпиляции, если что не так, просто изменяем скрипт... о! работает. Интересно на больших объемах все будет хорошо? мб лучше логику выносить из БД... Знаю что некоторые программисты на PHP выносят логику в MySQL, мотивируя что логика (например операторы if и for ) в PHP меднение чем то же в mysql, но возникает вопрос как разгрузить БД при больших нагрузках, PHP то можно разнести по разным веб-серверам без проблем, а вот MySQL как? В MySQL вроде можно как то делать кластер но что он даст я хз. зы про логику в PHP и MySQL за что купил за то продал ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 09:01:18 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
Var79...Интересно на больших объемах все будет хорошо?... Никто не знает, что такое "большие объёмы". У меня, например, был опыт, когда на всего паре сотен тыщь записей, запрос к MS SQL работал около часа. Немного подправил скрипт, и чудо свершилось 100 миллисекунд всего лишь! ПС. Кстати, вопросы с масшабируемостью и т.д., хотя они и редко возникают, если правильные индексы, правильные констраинты, и не налеплено "на всякий случай" вместо "INNER JOIN" "LEFT JOIN", на уровне БД решаются достаточно просто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 09:54:57 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
большие объемы, это когда думаешь "а не разнести ли мне сайт по разным серверам" :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 21:11:19 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
> Реализуйте всю бизнес-логику на SQL, Вы не поверите, но именно для этого он и существует. Тогда у Вас такой вопрос не появится в принципе. Очень спорный совет. Очень. SQL предназначен для работы с реляционными данными. Использование SQL или процедурных расширений типа T-SQL/PLSQL для реализации бизнес логики в текущий момент, IMHO, происходит от незнание того, как это можно сделать по другому. Объяснять почему не буду. Для того чтобы дать совет по существу не хватает данных о задаче. Возможно, лучше использовать какой-нибудь скриптовый язык, возможно, какой нибудь язык основанный на бизнес правилах (http://en.wikipedia.org/wiki/Business_rules_engine), к примеру, Drools, возможно, требуется какое-нибудь ETL (http://en.wikipedia.org/wiki/Extract,_transform,_load) решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2010, 12:59:34 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
kolchanov...Очень спорный совет... Хороший совет. Проверялось много раз. Не мной одним. Что можно сделать на TSQL, например, на нём и надо делать. Остальное - интерфейс и больше ничего. Конечно, если БД ничего не умеет делать... . А такие сейчас есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2010, 13:58:18 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
ShSergeЧто можно сделать на TSQL, например, на нём и надо делать. Остальное - интерфейс и больше ничего. Ну, не всегда, далеко не всегда. Даже такие простые вещи как решение СЛАУ, на TSQL выглядят не только извращением, но ещё и сильно ограничивают потенциальные возможности работы ПО (при приемлемом потреблении ресурсов, в первую очередь -- времени). Хотя с первым предложением в отдельности от второго, с акцентом на "что можно сделать", я бы согласился. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2010, 14:02:41 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
junior idiot...Даже такие простые вещи как решение СЛАУ... Система линейных уравнений? Ну, в принципе, да. Хотя, если коэффициенты хранятся в базе, я бы ещё подумал... . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2010, 14:12:09 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
Коэффициенты можно и занести во временные таблички, не суть. Скорее зависит от вида матрицы и, следовательно, выбранного алгоритма. Метод Гаусса ещё с горем пополам впихивается без особых потерь в производительности, НО выглядит уродливо, и сам алгоритм в коде не виден, т.к. имеет место жуткое смешение императивного и декларативного кода. А уж что будет с каким-нибудь разложением Холецкого и представить страшно. Вот примерно такое мракобесие может получиться, и это только для простейшего метода Гаусса: Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2010, 14:27:36 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
junior idiot, А чё там мракобесного? Там комментариев намного больше, чем кода. Если их убрать - фигня останется. Хотя, не могу не согласиться, что SQL для этого - не лучший выбор. Скажем, одно дело - математика, а другое - чисто работа с данными. Наверное, я слишком категорично выразился. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2010, 15:02:11 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
> Хороший совет. Проверялось много раз. Не мной одним. Мной тоже проверялось, и тоже не один раз. Очень хорошее решение для одних условий, очень плохое для других. Просто вы безапелляционно рекомендуете это решение как универсальный silver bullet, которых, как известно, просто нет. 10 лет назад я сам был апологетом такого подхода - все на хранимых процедурах и SQL. Первый раз столкнулся с его ограничениями, когда значительное увеличение пользователей и нагрузки привело к тому, что стоимость оборудование + стоимость enterprise лицензий стала превышать любой разумный бюджет. Во второй раз, в другом проекте, производительности *любого* существовавшего на тот момент кластера unix серверов было уже недостаточно для комфортной работы пользователей. Масштабируемость - одно из ограничений такого решения. Люди выдумывают различные подходы не потому что они дураки, или им нечем заняться, а потому что превысили область применения более простых решений. Вы, судя по всему, не сталкивались с такими задачами. Главная проблема, насколько я понял автора данного топика, отсутствие гибкости и сложность поддержки существующего кода. Я не знаю, что можно порекомендовать, абсолютно не хвататет данных. Но если говорить об абстрактной гибкости, попробуйте для себя сравнить гибкость решения на базе Business Rules и SQL. На мой взгляд, вывод очевиден. Если же нужно просто перенести данные из одной таблице в другую с простой трансформацией - нет ничего лучше SQL запроса. Я просто хотел сказать, что за пределами SQL тоже есть жизнь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2010, 15:04:03 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
ShSergeТам комментариев намного больше, чем кода. Если их убрать - фигня останется. Если их убрать, то даже автор кода будет впадать в минутный ступор при его прочтении. И, кажется мне, это именно неустранимый минус подхода, а не минус именно данной конкретной реализации. Впрочем, допускаю, что можно сделать и красиво, но я не знаю как. ShSergeСкажем, одно дело - математика, а другое - чисто работа с данными. Да, именно это и я хотел сказать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2010, 15:47:39 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
не буду скрывать, что подход от kolchanov мне более симпатичен своей взвешенностью. вскоре отпишу подробнее про задачу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2010, 15:48:17 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
kolchanovГлавная проблема, насколько я понял автора данного топика, отсутствие гибкости и сложность поддержки существующего кода. Я не знаю, что можно порекомендовать, абсолютно не хвататет данных. Да, существующее решение потеряло гибкость, когда потребовалось вводить существенную многовариантность реакций на приходящие данные. Делфи вкупе с моим линейным стилем программирования достаточно хорош, если задача четко поставлена и ее надо реализовать. Но задача оказалась достаточно гибкой сама по себе, идеи приходили по мере развития проекта: а давай сделаем так, а давай навесим такой параметр... в результате программа обвесилась кучей закладок, эдит-контролов, галок, графиков и стала похожа на новогоднюю ёлку, когда мы уже сами с трудом вспоминаем, что именно делает тот или иной редкоиспользуемый параметр. Больше того, в силу большого количества линейности (дельфи ведь гибридный язык, хочешь используй его ООП, хочешь нет) этот монстр стал сбоить внутренними непредсказуемыми связями. В качестве частичного решения проблемы мы стали выделять отдельные модули, которые решают конкретные задачи. Эти модули периодически отчитываются в базу "я жив", и мы сделали соответственно "следилку" за жизнью этих модулей. Стало легче, но достаточной алгоритмической гибкости по-прежнему нет. Задачи - такого рода: * при поступлении свежих данных в такую-то таблицу (сейчас это делается просто периодическим опросом этой таблицы с суб-секундными интервалами) пересчитать ситуацию (с учетом данных из нескольких таблиц), причем с достаточным количеством математики, и отреагировать - в зависимости от заложенного алгоритма отклика сделать или не сделать запись в другую таблицу; математика такая, что у меня есть определенные сомнения в логичности и прозрачности ее вешания на SQL: например, прямая функция (с функцией нормального распределения и логарифмами) и обратная (перебором значений прямой функции); * если от такого-то модуля (скажем, поставщика данных) нет ответа, скажем, 30 секунд ("умер" по какой-то причине), то надо переключиться на другой, запасной, послав сообщение (все общение - через соотв таблицу в базе), либо сделав что-то более сложное (например, переключение в несколько этапов, дожидаясь на каждом этапе отклика активации от задействованных модулей) * каждую, скажем, минуту анализировать данные за эту прошедшую минуту и писать summary о ней ... Сырые данные - это поток из нескольких десятков записей в секунду. В идеале - реакция на каждое изменение. В текущем исполнении - когда у очередного модуля подходит время цикла, данные забираются из БД внутрь этого модуля, там обрабатываются в течение порядка сотни мс, и модуль выдает свою реакцию. Хотелось бы вообще уйти от таких windows-оформленных модулей: пусть на сервере крутятся некие алгоритмические скрипты, данные от которых лежат в той же БД, а доступ ко всему этому хозяйству (к параметрам скриптов, к самим скриптам, к графикам, к диагностике жизни скриптов) - удаленный через веб-интерфейс. Не устраивают какие-то отклики системы - залез, подправил скрипт/параметр, написал новый алгоритм через новый скрипт, запустил/активировал его. зы. Мда. Чем больше пишу, тем больше понимаю: нужна консультация (скорее даже платная) от сведущего человека, который потратит время, погрузится в тематику и поможет выбрать подходящие инструменты из моря существующих софтовых технологий. В голове - полная каша. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2010, 17:50:49 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
daybit Сырые данные - это поток из нескольких десятков записей в секунду. В идеале - реакция на каждое изменение. В текущем исполнении - когда у очередного модуля подходит время цикла, данные забираются из БД внутрь этого модуля, там обрабатываются в течение порядка сотни мс, и модуль выдает свою реакцию. Чем больше пишу, тем больше понимаю: нужна консультация (скорее даже платная) от сведущего человека, который потратит время, погрузится в тематику и поможет выбрать подходящие инструменты из моря существующих софтовых технологий. Раз у вас математика то php отпадает Раз у вас MySQL то возможно не захотите использовать платные продукты Microsoft, хотя MSMQ, Service Broker , MS SQL и ASP.NET , C# очень вкусные продукты и вполне возможно как раз для вас. Java если предыдущий пункт вам не подходит ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2010, 21:13:25 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
Угу. Явка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2010, 21:25:14 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
Математику и на c++ не зазорно лабать, зачем для этого еще виртуальную машину явы? Коннектор для c++ к mysql имеется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2010, 21:38:52 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
Edd.DragonМатематику и на c++ не зазорно лабать, зачем для этого еще виртуальную машину явы? Коннектор для c++ к mysql имеется. Можно и на сях, только в этом случае маленько побольше знать и уметь надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2010, 21:46:51 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
ShSergedaybit, Реализуйте всю бизнес-логику на SQL, Вы не поверите, но именно для этого он и существует. Тогда у Вас такой вопрос не появится в принципе. Присоединюсь к ТС. У мну есть подобная система. Не на MySQL+Delphi, но неважно. Работает 24х7, но.... Не нравится мне архитектур. Есть некоторые траблы. Ниже. авторСырые данные - это поток из нескольких десятков записей в секунду. В идеале - реакция на каждое изменение. В текущем исполнении - когда у очередного модуля подходит время цикла, данные забираются из БД внутрь этого модуля, там обрабатываются в течение порядка сотни мс, и модуль выдает свою реакцию. Так вот, расчетные модули (у нас потоки): -не знают, когда сырые данные обновились. Нужно запрашивать max(time) -при записи в расчетные данные (общие таблицы) мешают друг другу -усугубление - расчет одного модуля зависит от результатов расчета другого, мешание усугубляется Особо не мешает, но мысль "какбысделать правильно и красиво"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2010, 23:58:02 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
Мне кажется, последовательность должна быть примерно следующей: 1. Либо найти человека, либо самому проанализировать существующее приложение, выяснить формальные требования, описать концептуально (например, в visio или в чем-то похожем) из каких логических модулей состоит приложение, и как эти модули друг от друга зависят. 2. Понять, какие связи между модулями лишние, выделить логические слои и нарисовать, как это *должно* быть. Нужно чтобы логические модули были достаточно независимы друг от друга. 3. Каждый такой модуль должен стать фасадным объектом (http://en.wikipedia.org/wiki/Facade_pattern), за которым скрывается мат. логика обработки и параметризация. 4. Выбрать какой-нибудь Dependency Injection Framework, который позволит декларативно компоновать эти модули и будет навязывать best practice подходы при проектировании приложения и интерфейсов. 5. В качестве языка реализующего логику выбрать какой-нибудь современный высокоуровневый функциональны язык, так как высокой производительности не требуется, а нужна гибкость и прозрачность. 6. Уйти от использования базы данных в качестве обмена данными между модулями/потоками. Посмотрите в сторону Actor model (http://en.wikipedia.org/wiki/Actor_model) Т.е. сосредоточится нужно не на том на чем на до писать, а на том как. Лично я бы для пункта 4 выбрал Spring Framework, для пункта 5 - scala или groovy, пункта 6 - akkasource. Не навязываю и не предлагаю, так как писать лучше на том, на чем лучше умеешь. В .Net мире, к примеру, есть аналогичные решения. Наверное это все что можно за 10 минут написать по этому поводу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2010, 00:16:15 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
ShSerge, идеи есть? kolchanov, это слишком общие верные советы, чтобы их обсуждать или критиковать =) Единственное - п.6 - тут могу сказать, что не подойдет, т.к. результаты все= писать в базу. Экономия на [неблокируемом] чтении??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2010, 10:44:55 |
|
||
|
на чем писать серверные скрипты
|
|||
|---|---|---|---|
|
#18+
> Единственное - п.6 - тут могу сказать, что не подойдет, т.к. результаты все= писать в базу. Экономия на [неблокируемом] чтении??? Никто не мешает Actor-у записать результат в базу и кинуть сообщение следующему по цепочке или диспетчеру. Главное что может дать такой подход - перейти от pull к push модели. Зачем модулю/потоку постоянно спрашивать, если для него новая порция данных? Как только данные будут готовы и Actor будет готов из обрабатывать соответствующий обработчик будет вызван. В идеале, чтений вообще может не быть. Не нравится Actor model - существует много push моделей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2010, 11:05:03 |
|
||
|
|

start [/forum/topic.php?fid=16&fpage=97&tid=1343453]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
27ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 199ms |
| total: | 324ms |

| 0 / 0 |
