powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Программирование [игнор отключен] [закрыт для гостей] / на чем писать серверные скрипты
25 сообщений из 28, страница 1 из 2
на чем писать серверные скрипты
    #36844359
daybit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Пишу автоматизированную систему обработки данных. На удаленном сервере стоит виртуальная машина с OpenSuse (Linux), на ней стоит база данных MySQL, в которую сваливаются "сырые" данные. На параллельной виртуальной машине стоит Windows, на котором работает мой расчетный модуль, написанный на Delphi. По мере поступления свежих данных в базу расчетный модуль эти данные берёт, обрабатывает, и результат обработки складывает обратно в базу. По истечении года развития Дельфи-проект стал чересчур тяжеловесным и не очень надежным - слишком много в нем пересекается логики, слишком много идей, о которых было неизвестно с самого начала, нашлепывалось по ходу дела.

Теперь процесс обработки данных оптимизируется. И вот пришла мысль, что мой подход вообще неоптимален. Множество элементарных расчетных операций можно было бы делать мелкими модулями, каждый из которых отвечал бы за небольшую часть: берет конкретные данные из MySQL, обрабатывает их и складывает результат обратно в MySQL , остальное - не его дело. Плюс к этому, хотелось бы иметь гибкость в редактировании алгоритмов обработки без необходимости постоянно компилировать исполняемый модуль - то есть некая скриптовость. И вот думается: а зачем реализовывать это все на дельфи, если и без того существуют интерпретируемые скриптовые языки программирования типа Perl. Представляется такая схема - некий очередной скрипт пишется, хранится в той же базе, активизируется юзером когда нужно, и выполняет свою часть вычислений. Спрашивается - что бы это могло быть? Perl-интерпретатор, Java, что-то другое? Где его разместить - на той же Linux-машине? С перлом я не знаком, да и с линуксом тоже не особо - скажем, там же тоже надо как-то следить за утечкой памяти, как это случается с моими дельфи-монстрами на виндах?

Интересны любые мысли на тему.
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36844371
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
daybit,

Реализуйте всю бизнес-логику на SQL, Вы не поверите, но именно для этого он и существует. Тогда у Вас такой вопрос не появится в принципе.
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36844393
daybit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ShSerge,
как это сделать? Все расчетные циклы, условия, синусы-косинусы? И как MySQL будет запускать эти расчеты? Какие-то триггеры прихода данных? MySQL это все умеет сам, без нашлепок? До этого я использовал его исключительно в качестве хранилища. )
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36844417
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
daybit,

Современные базы данных всё это умеют прекрасно делать с помощью SQL. По правде сказать, MySQL этому не так давно научился. Теперь имеются триггеры, х-ые процедуры и функции. Короче, ясен помидор, всю бизнес-логику можно (и нужно!) перенести на уровень БД. Вы удивитесь, насколько просты станут Ваши программы. Типа, написал запрос, написал интерфейс - ура!, работает. Никакой перекомпиляции, если что не так, просто изменяем скрипт... о! работает.
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36844707
Var79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShSergedaybit,

Современные базы данных всё это умеют прекрасно делать с помощью SQL. По правде сказать, MySQL этому не так давно научился. Теперь имеются триггеры, х-ые процедуры и функции. Короче, ясен помидор, всю бизнес-логику можно (и нужно!) перенести на уровень БД. Вы удивитесь, насколько просты станут Ваши программы. Типа, написал запрос, написал интерфейс - ура!, работает. Никакой перекомпиляции, если что не так, просто изменяем скрипт... о! работает.

Интересно на больших объемах все будет хорошо? мб лучше логику выносить из БД...
Знаю что некоторые программисты на PHP выносят логику в MySQL, мотивируя что логика (например операторы if и for ) в PHP меднение чем то же в mysql, но возникает вопрос как разгрузить БД при больших нагрузках, PHP то можно разнести по разным веб-серверам без проблем, а вот MySQL как? В MySQL вроде можно как то делать кластер но что он даст я хз.

зы
про логику в PHP и MySQL за что купил за то продал
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36844803
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Var79...Интересно на больших объемах все будет хорошо?...
Никто не знает, что такое "большие объёмы". У меня, например, был опыт, когда на всего паре сотен тыщь записей, запрос к MS SQL работал около часа. Немного подправил скрипт, и чудо свершилось 100 миллисекунд всего лишь!
ПС. Кстати, вопросы с масшабируемостью и т.д., хотя они и редко возникают, если правильные индексы, правильные констраинты, и не налеплено "на всякий случай" вместо "INNER JOIN" "LEFT JOIN", на уровне БД решаются достаточно просто.
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36846498
Var79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
большие объемы, это когда думаешь "а не разнести ли мне сайт по разным серверам" :)
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36847540
kolchanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> Реализуйте всю бизнес-логику на 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) решение.
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36847741
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kolchanov...Очень спорный совет...
Хороший совет. Проверялось много раз. Не мной одним. Что можно сделать на TSQL, например, на нём и надо делать. Остальное - интерфейс и больше ничего. Конечно, если БД ничего не умеет делать... . А такие сейчас есть?
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36847753
junior  idiot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ShSergeЧто можно сделать на TSQL, например, на нём и надо делать. Остальное - интерфейс и больше ничего.
Ну, не всегда, далеко не всегда.
Даже такие простые вещи как решение СЛАУ, на TSQL выглядят не только извращением, но ещё и сильно ограничивают потенциальные возможности работы ПО (при приемлемом потреблении ресурсов, в первую очередь -- времени).
Хотя с первым предложением в отдельности от второго, с акцентом на "что можно сделать", я бы согласился.
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36847782
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
junior idiot...Даже такие простые вещи как решение СЛАУ...
Система линейных уравнений? Ну, в принципе, да. Хотя, если коэффициенты хранятся в базе, я бы ещё подумал... .
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36847839
junior  idiot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Коэффициенты можно и занести во временные таблички, не суть. Скорее зависит от вида матрицы и, следовательно, выбранного алгоритма.
Метод Гаусса ещё с горем пополам впихивается без особых потерь в производительности, НО выглядит уродливо, и сам алгоритм в коде не виден, т.к. имеет место жуткое смешение императивного и декларативного кода. А уж что будет с каким-нибудь разложением Холецкого и представить страшно.

Вот примерно такое мракобесие может получиться, и это только для простейшего метода Гаусса:

Код: 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.
DECLARE
	@i	INT
	,@j	INT
	,@n	INT
	,@a	NUMERIC( 38 , 20 )
	,@k	NUMERIC( 38 , 20 )

-- получаем размерность матрицы
SET @n = (SELECT MAX(i) FROM [#HaussTbl])

-- по договоренности полагается, что 
--	в i > 0, j = 0 в таблице (поле a) хранятся правые части i-ых уравнений ( свободные члены )
--	в i > 0, j > 0 хранится коэффициент (a) перед j-ой переменной в i-ом уравнении
--	в i = 0, j > 0 после окончания хранимой процедуры содержат решение для j-ой переменной

-- диагонализация матрицы
SET @i =  1 
WHILE @i <= @n -- в @i - номер уравнения, в котором коэффициенты перед всеми переменными до @i (не включительно) должны стать равными нулю; при этом коэффициент в @i-ом уравнении перед @i-ой неизвестной должен быть равен единице
BEGIN
	-- обнуление коэффициентов перед @i-ой переменной во всех уравнениях с номером больше @i;
	-- коэффициент перед @i-ой переменной в @i-ом уравнении должен стать равным единице
	SET @j = @i
	WHILE @j <= @n -- @j - номер обрабатываемого уравнения (Все уравнения с номером меньше @i уже обработаны и трогать их не надо)
	BEGIN
		-- получаем коэффициент перед @i-ой переменной в @j-ом уравнении (обрабатываемом)
		SET @a = (SELECT TOP  1  a FROM [#HaussTbl] WHERE i = @j and j = @i)
		-- вычисляем коэффициент @k на который требуется домножить @j-ое уравнение, чтобы коэффициент перед @i-ой переменной стал равен единице
		-- вообще говоря, @a должен не быть равным нулю при @j = @i; в случае с себестоимостью такая ситуация означает, что вх. сальдо, вх. перемещения и закупки равны нулю за расчитываемый период для данного счета
		--	т.е. понятие "себестоимость" с т.з. математики не имеет смысла (не определено);
		--	по договоренности: такие себестоимости полагаются равными нулю
		--	при этом следует понимать, что все коэффициенты перед такой переменной во всех уравнениях уже должны быть равны нулю, и принудительное обнуление не должно на самом деле ничего изменить;
		--	если же коэффициент в каком-либо уравнении при данной переменной ненулевой, это означает, что было исх. складское перемещение со счета @i, причем вх. сальдо на @i равно нулю, т.е. это ошибка в данных, что приведет к неопределенному поведению программы.
		-- если же @a = 0 для @j > @i, то это просто означает что никаких изменений в @j-ом уравнении проводить не нужно: оно уже в требуемой форме
		IF @a <>  0 
		BEGIN
			SET @k =  1  / @a
			-- домножаем @j-ое уравнение на коэффициент @k
			-- при этом коэффициент перед @i-ой переменной станет равным единице
			UPDATE [#HaussTbl] SET a = a * @k WHERE i = @j and i <>  0 
			-- если уравнение @j > @i, то требуется обнулить коэффициент перед @i-ой переменной
			-- для этого вычитаем из @j-ого уравнения @i-ое уравнение
			-- при
			IF @j > @i
				UPDATE [#HaussTbl] SET 
					a = a - (
						SELECT TOP  1  t.a 
						FROM [#HaussTbl] t 
						WHERE t.i = @i and t.j = [#HaussTbl].j) 
				WHERE i = @j
			END
		ELSE IF @j = @i -- себестоисть не определена; обнулить коэффициенты во всех уравнениях, и само @i-ое уравнение ( на всякий случай )))
		BEGIN
			UPDATE [#HaussTbl] SET a =  0 
			WHERE (i > @j and j = @i) or (i = @j)
		END

		SET @j = @j +  1 
	END

	SET @i = @i +  1 
END

-- "раскрутка" в обратном (снизу вверх) порядке по диагонализированной матрице, сразу выписываем решение и вычитаем то что нужно из всех уравнений, выше обрабатываемого
SET @i = @n
WHILE @i >=  1 
BEGIN
	-- берем правую часть уравнения ( свободный член )
	SET @a = (SELECT TOP  1  a FROM [#HaussTbl] WHERE i = @i and j =  0 )
	-- для всех переменных с ненулевыми коэффициентами (из значения уже должны быть известны) - вычесть из свободного члена соответствующее число (xi*ai)
	SET @j = @n
	WHILE @j > @i
	BEGIN
		SET @a = @a - (SELECT TOP  1  a FROM [#HaussTbl] WHERE i =  0  and j = @j) * (SELECT TOP  1  a FROM [#HaussTbl] WHERE i = @i and j = @j)
		SET @j = @j -  1 
	END

	INSERT INTO [#HaussTbl] (i,j,a) VALUES ( 0 ,@i,@a)

	SET @i = @i -  1 
END
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36847971
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
junior idiot,

А чё там мракобесного? Там комментариев намного больше, чем кода. Если их убрать - фигня останется.
Хотя, не могу не согласиться, что SQL для этого - не лучший выбор.
Скажем, одно дело - математика, а другое - чисто работа с данными. Наверное, я слишком категорично выразился.
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36847978
kolchanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> Хороший совет. Проверялось много раз. Не мной одним.
Мной тоже проверялось, и тоже не один раз.
Очень хорошее решение для одних условий, очень плохое для других.
Просто вы безапелляционно рекомендуете это решение как универсальный silver bullet, которых, как известно, просто нет.

10 лет назад я сам был апологетом такого подхода - все на хранимых процедурах и SQL.
Первый раз столкнулся с его ограничениями, когда значительное увеличение пользователей и нагрузки привело к тому, что стоимость оборудование + стоимость enterprise лицензий стала превышать любой разумный бюджет.
Во второй раз, в другом проекте, производительности *любого* существовавшего на тот момент кластера unix серверов было уже недостаточно для комфортной работы пользователей.
Масштабируемость - одно из ограничений такого решения.

Люди выдумывают различные подходы не потому что они дураки, или им нечем заняться, а потому что превысили область применения более простых решений.
Вы, судя по всему, не сталкивались с такими задачами.

Главная проблема, насколько я понял автора данного топика, отсутствие гибкости и сложность поддержки существующего кода. Я не знаю, что можно порекомендовать, абсолютно не хвататет данных.
Но если говорить об абстрактной гибкости, попробуйте для себя сравнить гибкость решения на базе Business Rules и SQL. На мой взгляд, вывод очевиден.
Если же нужно просто перенести данные из одной таблице в другую с простой трансформацией - нет ничего лучше SQL запроса.

Я просто хотел сказать, что за пределами SQL тоже есть жизнь.
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36848189
junior  idiot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ShSergeТам комментариев намного больше, чем кода. Если их убрать - фигня останется.
Если их убрать, то даже автор кода будет впадать в минутный ступор при его прочтении. И, кажется мне, это именно неустранимый минус подхода, а не минус именно данной конкретной реализации. Впрочем, допускаю, что можно сделать и красиво, но я не знаю как.

ShSergeСкажем, одно дело - математика, а другое - чисто работа с данными.
Да, именно это и я хотел сказать.
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36848196
daybit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
не буду скрывать, что подход от kolchanov мне более симпатичен своей взвешенностью. вскоре отпишу подробнее про задачу
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36848713
daybit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kolchanovГлавная проблема, насколько я понял автора данного топика, отсутствие гибкости и сложность поддержки существующего кода. Я не знаю, что можно порекомендовать, абсолютно не хвататет данных.

Да, существующее решение потеряло гибкость, когда потребовалось вводить существенную многовариантность реакций на приходящие данные. Делфи вкупе с моим линейным стилем программирования достаточно хорош, если задача четко поставлена и ее надо реализовать. Но задача оказалась достаточно гибкой сама по себе, идеи приходили по мере развития проекта: а давай сделаем так, а давай навесим такой параметр... в результате программа обвесилась кучей закладок, эдит-контролов, галок, графиков и стала похожа на новогоднюю ёлку, когда мы уже сами с трудом вспоминаем, что именно делает тот или иной редкоиспользуемый параметр. Больше того, в силу большого количества линейности (дельфи ведь гибридный язык, хочешь используй его ООП, хочешь нет) этот монстр стал сбоить внутренними непредсказуемыми связями. В качестве частичного решения проблемы мы стали выделять отдельные модули, которые решают конкретные задачи. Эти модули периодически отчитываются в базу "я жив", и мы сделали соответственно "следилку" за жизнью этих модулей. Стало легче, но достаточной алгоритмической гибкости по-прежнему нет. Задачи - такого рода:
* при поступлении свежих данных в такую-то таблицу (сейчас это делается просто периодическим опросом этой таблицы с суб-секундными интервалами) пересчитать ситуацию (с учетом данных из нескольких таблиц), причем с достаточным количеством математики, и отреагировать - в зависимости от заложенного алгоритма отклика сделать или не сделать запись в другую таблицу; математика такая, что у меня есть определенные сомнения в логичности и прозрачности ее вешания на SQL: например, прямая функция (с функцией нормального распределения и логарифмами) и обратная (перебором значений прямой функции);
* если от такого-то модуля (скажем, поставщика данных) нет ответа, скажем, 30 секунд ("умер" по какой-то причине), то надо переключиться на другой, запасной, послав сообщение (все общение - через соотв таблицу в базе), либо сделав что-то более сложное (например, переключение в несколько этапов, дожидаясь на каждом этапе отклика активации от задействованных модулей)
* каждую, скажем, минуту анализировать данные за эту прошедшую минуту и писать summary о ней
...

Сырые данные - это поток из нескольких десятков записей в секунду. В идеале - реакция на каждое изменение. В текущем исполнении - когда у очередного модуля подходит время цикла, данные забираются из БД внутрь этого модуля, там обрабатываются в течение порядка сотни мс, и модуль выдает свою реакцию. Хотелось бы вообще уйти от таких windows-оформленных модулей: пусть на сервере крутятся некие алгоритмические скрипты, данные от которых лежат в той же БД, а доступ ко всему этому хозяйству (к параметрам скриптов, к самим скриптам, к графикам, к диагностике жизни скриптов) - удаленный через веб-интерфейс. Не устраивают какие-то отклики системы - залез, подправил скрипт/параметр, написал новый алгоритм через новый скрипт, запустил/активировал его.

зы. Мда. Чем больше пишу, тем больше понимаю: нужна консультация (скорее даже платная) от сведущего человека, который потратит время, погрузится в тематику и поможет выбрать подходящие инструменты из моря существующих софтовых технологий. В голове - полная каша.
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36849027
Var79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
daybit
Сырые данные - это поток из нескольких десятков записей в секунду. В идеале - реакция на каждое изменение. В текущем исполнении - когда у очередного модуля подходит время цикла, данные забираются из БД внутрь этого модуля, там обрабатываются в течение порядка сотни мс, и модуль выдает свою реакцию.
Чем больше пишу, тем больше понимаю: нужна консультация (скорее даже платная) от сведущего человека, который потратит время, погрузится в тематику и поможет выбрать подходящие инструменты из моря существующих софтовых технологий.

Раз у вас математика то php отпадает

Раз у вас MySQL то возможно не захотите использовать платные продукты Microsoft, хотя MSMQ, Service Broker , MS SQL и ASP.NET , C# очень вкусные продукты и вполне возможно как раз для вас.

Java если предыдущий пункт вам не подходит
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36849042
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Угу. Явка.
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36849066
Edd.Dragon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Математику и на c++ не зазорно лабать, зачем для этого еще виртуальную машину явы? Коннектор для c++ к mysql имеется.
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36849075
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Edd.DragonМатематику и на c++ не зазорно лабать, зачем для этого еще виртуальную машину явы? Коннектор для c++ к mysql имеется.
Можно и на сях, только в этом случае маленько побольше знать и уметь надо.
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36849199
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShSergedaybit,

Реализуйте всю бизнес-логику на SQL, Вы не поверите, но именно для этого он и существует. Тогда у Вас такой вопрос не появится в принципе.
Присоединюсь к ТС.
У мну есть подобная система. Не на MySQL+Delphi, но неважно. Работает 24х7, но....

Не нравится мне архитектур. Есть некоторые траблы. Ниже.

авторСырые данные - это поток из нескольких десятков записей в секунду. В идеале - реакция на каждое изменение. В текущем исполнении - когда у очередного модуля подходит время цикла, данные забираются из БД внутрь этого модуля, там обрабатываются в течение порядка сотни мс, и модуль выдает свою реакцию.
Так вот, расчетные модули (у нас потоки):
-не знают, когда сырые данные обновились. Нужно запрашивать max(time)
-при записи в расчетные данные (общие таблицы) мешают друг другу
-усугубление - расчет одного модуля зависит от результатов расчета другого, мешание усугубляется

Особо не мешает, но мысль "какбысделать правильно и красиво"?
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36849208
kolchanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мне кажется, последовательность должна быть примерно следующей:

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 минут написать по этому поводу.
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36849556
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShSerge, идеи есть?

kolchanov, это слишком общие верные советы, чтобы их обсуждать или критиковать =)
Единственное - п.6 - тут могу сказать, что не подойдет, т.к. результаты все= писать в базу. Экономия на [неблокируемом] чтении???
...
Рейтинг: 0 / 0
на чем писать серверные скрипты
    #36849620
kolchanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> Единственное - п.6 - тут могу сказать, что не подойдет, т.к. результаты все= писать в базу. Экономия на [неблокируемом] чтении???

Никто не мешает Actor-у записать результат в базу и кинуть сообщение следующему по цепочке или диспетчеру.
Главное что может дать такой подход - перейти от pull к push модели.

Зачем модулю/потоку постоянно спрашивать, если для него новая порция данных?
Как только данные будут готовы и Actor будет готов из обрабатывать соответствующий обработчик будет вызван.
В идеале, чтений вообще может не быть.
Не нравится Actor model - существует много push моделей.
...
Рейтинг: 0 / 0
25 сообщений из 28, страница 1 из 2
Форумы / Программирование [игнор отключен] [закрыт для гостей] / на чем писать серверные скрипты
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]