Овчинка выделки не стоит. Скорость обработки данных определяется движком базы, а не способом обращения к нему. Функции на С будут содержать намного больше кода (в три раза больше, чем на перле, в десять раз больше, чем на тикле, проверено на нескольких проектах), потребуют тестирования на нескольких машинах, в то время как процедурные на порядок лаконичнее и не требуют сложного тестирования и установки (не зависят от ОС и "железа").

Что касается кода - нет смысла его прятать, поскольку для осуществления адаптации вашего движка другим человеком он как разработчик должен иметь уровень на порядок выше вашего, плюс разобраться в архитектуре системы плюс знать бизнес-требования решаемой задачи. Специалист с таким уровнем сможет написать аналог, и не имея доступа к вашему коду. Так что выбрав C, вы только себе же жизнь усложните - бизнес сейчас очень динамичен и успех проекта определяется скоростью внесения вами изменений при изменении бизнес-правил. Если у вас все получится, вам будут платить за оперативность поддержки.

sybasesql
1. Позвольте с вами не согласиться. Ведь всегда есть оверхед у языка, на котором пишутся функции. Вы же не будете отрицать, что оверхед у tcl или perl гораздо больше чем у plain c.


Вы уверены, что написанная вами на С функция будет быстрее работать со строковыми данными? Обычно выходит как раз таки медленнее, поскольку функции операции со строками в скриптовых языках написаны на С очень качественно. В основном функции в базе оперируют sql-запросами, так что от них требуется именно работа со строками - генерация запросов и разбор параметров. Вы же не будете писать на встроенной в базу скриптовой функции преобразование Фурье (которое, кстати говоря, и при реализации на чистом С может иметь совсем разную производительность, в зависимости от компилятора и его опций).

sybasesql
Для нас главный критерий - это максимально спрятать исходный код и логику работу от пользователей системы. Тестирование же не проблема, т.к. у нас в штате есть тестеры.


Может быть, в вашем случае это так, однако зачастую время на тестирование ограничено, продляя тестирование - теряете деньги. А пользователям и код и логика без надобности.

sybasesql
2. Дело в том, что наша система будет сертифицироваться, как АПК, и вряд ли кто-то один будет писать подобное. Даже скажу большее, одним из критериев закрытости кода, как раз и стоит тот факт, чтоб наши клиенты обращались только к нам за доработкой, а не писали свои кривые костыли. Опять же та же техподдержка. По скорости внесения изменений и доработки так же не вижу проблем, т.к. проектом будет заниматься не один разработчик.


"Не вижу препятствий" (с). Сам занимаюсь разработкой и поставкой крупных ИС, притом добровольно предоставляю заказчикам исходники, в качестве определенной гарантии (их можно проверить на отсутствие "закладок" и т.д.). Значительный доход приносит именно техподдержка. Могу вас уверить, если будете предоставлять _качественную_ поддержку, вам будут платить. Так что решайте сами - закрытые исходники и расходовать силы на борьбу с пиратством (зачастую, вымышленным), или все силы на качество продукта. Когда клиентов будет много, разработчиков будет не хватать, независимо от их количества (а таких, кто знает систему "от и до" и может оперативно решить возникшую проблему, тем более). Прикиньте стоимость для клиента простоя системы и поймете, что такие расходы никому не нужны (про искажение данных в системе "кривыми костылями" даже говорить не стоит).

sybasesql
Мы параллельно рассматриваем вынос бизнес логики в отдельную сетевую службу на c/c++, которая будет взаимодействовать с СУБД и производить все расчеты. В этом подходе так же есть свои плюсы и минусы. Не понятно, что лучше будет работать в разрезе создания кластера и использования сервисов от скайп - plproxy, пул соединений, система бэкап?

Нет смысла. Все операции с данными надо делать в базе, иначе накладные расходы на передачу данных _слишком_ велики. Потеряете в производительности не в десятки раз - в сотни, если не более. И зачем вам кластер? Например, для системы документооборота, один сервер уровня пентиум Д с парой гиг памяти и саташным рэйдом может обслуживать несколько сотен или тысяч одновременных клиентов. Поставьте мощный сервер и не надо терять время на создание кластера. Если ваша команда не способна писать высокопроизводительные системы, задумайтесь над этим сейчас, не надо ждать, когда все сервера "вылетят" под нагрузкой, тогда уже и кластер не спасет.

sybasesql
В любом случае спасибо за ваше мнение.
Пожалуйста.

sybasesql
Вот как раз в этом и был один из основных вопросов. На сколько будет, если будет вобще, проиграешь в производительности, если все функции/процедуры/триггеры описывать исключительно на C?


В 10 раз по времени разработки, остальное зависит от квалификации разработчиков. Если ваша команда имеет опыт разработки для embedded devices (больше практически никто не способен писать по-настоящему эффективный и быстрый код на чистом С, конечно, исключая высококлассных разработчиков драйверов и ядра линукс и некоторых других, но их квалификацию оценить намного сложнее), то в производительности не проиграете. В иных случаях потери производительности могут быть огромными (тесты производительности делать очень сложно, поскольку время доступа к данным сильно варьируется и оценить скорость выполнения хранимок очень не просто). Скорость написания кода для профессионала не зависит от используемого языка, а объем кода на С на порядок больше. В итоге вы на С будете 3 года писать систему, которую можно сделать за 3 месяца. Ваш бизнес это выдержит? Мы несколько лет назад просто зашивались, когда писали на С всего лишь один крупный проект (да, там много всего было - сервер на линукс, десктопные клиенты на windows и мобильные на кпк под winmobile, плюс как обычно нечеткие спецификации и периодические изменения бизнес-правил, а мы заключали контракт на поставку и техподдержку системы и набора дополнительных модулей, т.е. приходилось поддерживать уже работающую систему и вносить требуемые доработки плюс писать новые модули), переход на тикль решил проблему, хотя мы начали переход _не зная тикль_. Тем не менее, за год переписали все, успели сделать еще один серьезный проект и перешли в нормальный режим поддержки и разработки дополнительных модулей. Что ж, это были тяжелые годы, но мы многому научились. Нам удалось спасти бизнес только благодаря энтузиазму команды. Хотите ли вы повторить этот путь?

sybasesql
Сервера в кластере мы планируем использовать самые мощные. На текущий момент закупается первый кластер из серверов следующей конфигурации: xeon 5400 серии на 1600 fsb, 64gb ram, 4xSAS 147GB 15000RPM в аппаратном RAID10. Для ускорения вычислений все, начиная от ОС и заканчивая СУБД и написанными функциями будет собранно под х64 платформу. Планируется использование двух серверов для pool - PgBouncer (один основной, второй failover), 3 БД сервера с размазанными (партицированными) по ним данными и один сервер для бэкапов - WalMgr.
Необходимость в кластере уже назрела, т.к. текущая система не справляется с тем ростом клиентской базы, а в следствии с ростом потока данных, которые мы имеем сейчас.

х64 бывает не только полезно, но и вредно. Многие вещи на этой платформе работают _медленнее_. Большая разрядность указателей, соответственно, большее потребление памяти, так что все не так просто. Посмотрите архивы рассылки debian-russian, этот вопрос периодически обсуждается. Это я к тому, что будьте готовы, что существенно потеряете в производительности. Использование кластеров - отдельная история, зачастую печальная, поскольку система, не спроектированная изначально под кластер, может работать на нем совсем не так, как вы ожидаете. Более того, масштабируемость линейной не бывает (зависит от архитектуры системы и много чего еще), так что использование двух серверов вместо одного не даст удвоения производительности (а может и вообще не дать _заметного_ эффекта).


P.S. Замечу, что я высказываю свои мысли не только на текущий момент, а на весь жизненный цикл продукта - составление ТЗ, проектирование, кодирование, тестирование, внедрение, сопровождение, поставка дополнительных расширений к системе, тиражирование. Может быть, вас весь этот путь не интересует (вы можете уволиться с текущего места работы, может что-то с вашей конторой случиться - от банкротства до смены вида деятельности и проч.), в таком случае мои наброски о том, что вас ожидает в течении двух-трех лет вам более интересны, чем полезны. Но - а вдруг вы пройдете до конца?