Московская биржа выбирает Linux

Всё больше серьезных организаций отказывается от Windows 10 и ее навязчивой слежки. Отказываются даже в России, где позиции Microsoft были особенно сильны. Из последних новостей: Московская биржа запилила торгово-клиринговую систему «Урожай» исключительно на базе свободных технологий и Linux. Windows? Спасибо, не нужно!

Система Урожай на Linux

Система позволяет проводить закупки сельхозпродукции через аукцион, оформлять договора и даже просчитывать логистику. Гордость Урожая — функция оформления договора на железнодорожную доставку в 1 клик. Купил 3 вагона картохи и тут же заключил договор на доставку. С такой инновационной системой голод россиянам больше не грозит.

Компоненты системы «Урожай»">
Назначение Программный продукт
Операционная система Red Hat Enterprise Linux
Платформа Red Hat JBoss Enterprise Application Platform
СУБД Firebird SQL
Web-сервер Nginx
Система обмена сообщениями RabbitMQ
Системный мониторинг Zabbix

Ну и как жизнь без Windows? Система Урожай на базе свободного софта успешно обрабатывает 50 тыс. биржевых заявок каждый день. И делает это настолько хорошо, что Урожай уже получил почетную премию за лучшее «облачное решение года».

5
Ваша оценка: Нет Средняя оценка: 5 (7 votes)

Тогда почему не CentOS ?
Нужна платная поддерка RHEL ?

Ваша оценка: Нет
pomodor

Не думаю. У таких проектов собственная мощная поддержка. Скорее, нужен маленький откаттинг. Но лучше так, чем Вантуз.

Ваша оценка: Нет Средняя оценка: 5 (5 votes)

За CentOS нет конкретной организации, а все закупки нужно провести по документам. Этим CentOS многих и не устраивает. Жаль, ведь ОС отличная, хоть и разрабатывается по принципу паразитизма.

Ваша оценка: Нет Средняя оценка: 4 (1 vote)

Если CentOS и Red Hat объединились,то о каком паразитизме реч ?

Ваша оценка: Нет

Интересен выбор Firebird.
Технически на сегодня это не самый продвинутый сервер.
С другой стороны именно Firebird является открытым и свободным ПО. С точки зрения импортозамещения, несколько странно, почему не стали использовать Yaffil. ;).

Если вспомнить, что основным рабочим терминалом хомячков на ММВБ является quik — кустарная поделка новосибирской фирмы, написанная то-ли на Delphi (как бы не на 4-5 версии), то-ли на C Builder, то выбор Firebird становится вполне понятным. Как минимум это говорит о том, что рабочие места можно будет писать на Delphi и конечно же под Windows. Так что писать "Windows? Спасибо, не нужно!" это неправильно. Скорее наоборот, рабочие места будут именно под Windows. Правда программы, скомпилированные в Delphi 7 легко запускаются на wine.
Ну и наконец производительность IB/FB, имхо, будет повыше, чем у MySQL. Кто не верит, сделайте к примеру 1000 запросов типа update/insert/delete на MySQL и FB, используя все средства ускорения того и того СУБД. Хоть и плюшек поменьше будет и база требует обслуживания (а какая не требует?). Про PostgeSQL не говорю т.к. он не бесплатен для коммерческих проектов, собственно и MySQL тоже.

Ваша оценка: Нет
pomodor

Умом выбор Firebird не понять. Сюда просится PostgreSQL. Да и 50 тыс. заявок в день — не так много. Кластер с MySQL тоже бы справился.

производительность IB/FB, имхо, будет повыше, чем у MySQL

Чой это? MySQL самая быстрая СУБД. Правда, больше заточена под Web.

Про PostgeSQL не говорю т.к. он не бесплатен

Чо? Смотрю лицензию: Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies.

собственно и MySQL тоже

Чо? MySQL open source software is provided under the GPL License.

Ваша оценка: Нет Средняя оценка: 5 (2 votes)

Чой это? MySQL самая быстрая СУБД. Правда, больше заточена под Web.

Да ладно. Для начала у MySQL нет параметрических запросов. Я же пояснил.
Максимум где можно ускорить MySQL это передать в одном insert сразу несколько значений для добавления, но при этом размер запроса будет ограничен max_allowed_packet. И если надо добавить несколько тысяч записей, это станет проблемой, необходимо писать скрипт для разбиения запроса на кусочки. В IB/FB можно создать параметрический запрос на insert и потом просто гнать в него только данные. Что касается update и, в меньшей степени, delete, то тут в MySQL вообще ничего не ускорить, только слать полностью текст запроса, который сервер каждый раз будет компилировать. И это не считая того, что таким образом приходится бороться с инъекциями. В IB/FB в параметрических запросах такой проблемы не существует в принципе. Для MySQL возможна только имитация параметрического запроса, что и делается некоторыми фреймворками (от DQE до Yii), но скорости это не добавляет.
Что касается PosgreSQL, я с нем работал очень мало, но скорее всего у него есть параметрические запросы на уровне СУБД как и в IB/FB.
Про заточку под web: и в чем она заключается? У MySQL, PSQL, IB/FB нет никаких web-спецефичных функций. Просто их берут и используют под Web.
Про кэширование запросов в MySQL: функция приятная, но к сожалению кэшируются только статические запросы т.к. у MySQL нет параметрических запросов. В связи с этим диапазон применений кэширования не такой уж и большой. Реализовать кэширование в FB на уровне фреймворка/приложения не так уж и сложно. Можно считать crc/sha контрольные суммы текста запроса и сохранять в таблице вместе с результатом. При некотором желании можно сделать кэширование и параметрических запросов.
В MySQL невозможно управлять планом выполнения запроса в FB можно. Бывают случаи, когда изменение плана приводит к существенному росту производительности. Часто это заметно, когда одни из таблиц имеет несколько тысяч (а то и десятков и сотен тысяч) записей, а связанная с ней — несколько сотен и результат получается относительно небольшой.
Про бесплатность: права на MySQL и PSQL принадлежат коммерческим конторам, которые в любой момент могут выпустить версии, лишив их GPL и преценденты есть, тот же Borland Interbase. FB изначально отпочковался от бесплатной IB (которую в следующей версии опять закрыли) и развивается как свободная система. От него можно только сделать свой форк и тогда попытаться сделать его платным, но сам FB останется свободным ПО.
Про фрагментацию БД: да у IB/FB есть такая проблема. Более того, сам файл БД при частом изменении метаданных часто приходит в такое состояние, что БД становится поврежденной. Что бы этого не происходило, необходимо как можно чаще пересоздавать БД. Особенно после операций ALTER, особенно тех, при которых менялись типы полей и ограничения на них типа "NOT NULL", "FOREIGN KEY". Пересоздание БД на лету невозможно, приходится отключать все соединения. Это издержки однофайлового СУБД (знаю, что можно несколько файлов, но по сути это один файл, порезаный по нескольким). Но есть и плюсы. Можно создать ramfs и нужную БД положить на ram-диск. MySQL или PSQL такое позволят? Они позволят положить все БД на ramfs, но не одну выбранную. Создание memory table это все-таки работа на уровне структуры БД, а не на уровне конфигурации сервера.
Отсутствие полнотекстовых индексов — да минус, но как всегда есть варианты. И опять же параметрические запросы помогут.
Так что в целом потенциал роста производительности в FB будет повыше, чем в MySQL. Надо только уметь пользоваться FB. Оно и понятно. MySQL изначально создавалась как простой (в реализации) и маленький СУБД. По сути он таковым и остается, хоть его код и разросся до приличных размеров, превысив размер FB. Но надо признать, что MySQL при этом активно наращивает количество инструментов и по идее поддерживает весьма широкий набор типов данных, таблиц, фич. Для FB было бы неплохо поддерживать такой набор. В целом для прототипирования MySQL подходит лучше, чем FB. FB скорее подходит для создания конечного продукта.

Ваша оценка: Нет Средняя оценка: 2.3 (3 votes)
Texnoline

Так что в целом потенциал роста производительности в FB будет повыше, чем в MySQL.

хм, после некоторой работы с базой (select, insert, update, delete) база начинает сильно тормозить, и простой запрос выполняемый 3-5 мс, начинает выполнятся 3000-5000 мс,к базе подключено 3 клиента, тормоза начинаются где-то после 20000-50000 select'ов и порядка 10000 insert/delete/update.

Ваша оценка: Нет Средняя оценка: 5 (1 vote)
reflexius

Согласен на 100%. Был у меня опыт работы с FB в качестве централизованной университетской СУБД. И тормоза были весьма и весьма выразительными. Скорее всего, выбор FB — это предпочтение разработчика.

Ваша оценка: Нет

Скорее всего Вы что-то не так спланировали в БД. Мой опыт — розничный магазин, 6 клиентских мест, СУБД на одноядерном Pentium 2,4GHz, RAID 0+1, RAM 512Mb, полнотекстовый поиск по наименованию товара. Часто одновременно к БД обращались по 2-3 клиентских места. Средняя скорость поиска по LIKE в таблице на 20000 записей около 0,1 сек. Может и меньше т.к. были кадры, умудряющиеся набрать поисковое слово быстрее, чем Celeron 700MHz на WinXP успевает вставлять символы в поле ввода. Сеть 10Мбит.
Далее, этот же сервер занимался выборкой OLAP (планирование закупок), анализировал в общей сложности несколько сот тысяч записей (декартово произведение справочника товаров и истории продаж и ревизий на несколько месяцев). На полный анализ хватало нескольких минут (субъективно около 2-3), из которых около минуты заполнялась матрица с результатом прогноза.
БОльшая часть расчета производилась хранимой процедурой на сервере. Клиент только сводил и заполнял результат вычислений в матрицу на экран.
Параллельно этот же сервер был файл-сервером для всей конторы, маршрутизатором, делал резервные копии каждые 30 минут. Я это описываю к тому, что бы показать, что сервер не простаивал, а был более-менее загружен работой. И это все делал одноядерный проц. Считай сейчас это делал бы какой-нибудь Atom N2600.
Второй опыт использования FB — магазин розничной торговли. Кассовое рабочее место со штрих-кодами. Все это крутилось на ноуте Celeron 1.5GHz. Он же сам себе и сервер и клиент, при этом еще крутил музыку в магазин, собирал изображения с камер наблюдения (FullHD, 3шт) и занимался репликацией данных (отчеты о продажах, приходы и т.д.) через GPRS-модем. Комп работал в реальном времени, музыка почти не тормозила. В данном случае именно тормоза музыки я использовал как критерий теста на производительность. Как только начинались тормоза, я начинал оптимизировать код рабочего места.
Сейчас поддерживаю сайт. Локально на моем компе (Core-i3 2GHz/RAM 4Gb) еле-еле крутится его тестовая версия сайта (ubuntu 16.04, apache2 + php5 + mysql). В БД товаров сопоставимое количество (20000-50000). Но справедливости ради надо сказать, что сейчас оптимизации запросов нет вообще, об оптимизации организации индексов вообще речи нет, предыдущие разработчики сделали отбор множеств товаров php-функцией array_intersect. В принципе можно было еще медленнее придумать, но уже пришлось бы на много больше писать.
Вот и делайте выводы о производительности FB. Ищите, где у Вас падение производительности. Изучайте планы запросов, создавайте индексы, задавайте планы выполнения руками, кладите базу на ramfs. Это здорово помогает. Ну и регулярно пересоздавайте базу. Я уже писал, что это зло, но зато можно одну БД положить на ramfs и использовать как read only, а остальные держать на диске.

Ваша оценка: Нет
pomodor

Идите работать в Facebook или Вконтакте главным инженером. А то на этих "небольших сайтиках" как-то всё MySQL пользуются. А надо, оказывается, Firebird ставить. Научите несмышленых. ;)

Ваша оценка: Нет Средняя оценка: 5 (2 votes)

Не надо передергивать.
Я не говорил, что надо обязательно FB на мелкие сайтики или на Facebook. MySQL очень неплохо справляется со своей задачей. Более того, я указал, что MySQL поддерживает такие типы данных и запросы, которые можно переносить на более мощные сервера (тот же полнотекстовый поиск или сравнение текстов). FB-же остановился где-то на уровне середины 2000-х и только подправляет свои баги в коде (и добавляет новые). Но и говорить о слабой производительности FB тоже не верно. Если MySQL и FB эксплуатировать верно, оба сервера имеют хорошие показатели. У меня складывается подозрение, что большинство (или все) комментаторов, пишущих о том, что у FB слабая производительность, просто не умеют им работать, точнее не умели когда работали с FB во время постижения азов программирования. Почти все пишут, что делали университетские/школьные/первые в жизни проекты т.е. явно пользовали FB во время своего обучения. Из чего еще можно сделать вывод, что как система для обучения, FB очень неплохо подходит.
Что де касается Facebook, VK: "Многие вещи существуют по недоразумению" (c)

Ваша оценка: Нет
reflexius

Про PostgeSQL не говорю т.к. он не бесплатен для коммерческих проектов, собственно и MySQL тоже.

Иногда просто удивляться приходится откуда берется такая информация. Это искренне или это троллинг такой? С лицензиями указанных СУБД знакомились? Если нет, то зачем писать всякую ахинею?

Согласно лицензии PostgreSQL (официальный сайт): "PostgreSQL распространяется по лицензии сходной с BSD и MIT. В своей основе она позволяет пользователям делать с кодом всё что угодно, включая перепродажу скомпилированных файлов без исходного кода. Единственное ограничение состоит в том, что вы можете возложить на нас юридическую ответственность за проблемы с этим программным обеспечением.".

Согласно лицензии MySQL (официальный сайт): "This is a release of MySQL, the dual-license open-source RDBMS . For the avoidance of doubt, this particular copy of the software is released under version 2 of the GNU General Public License".

Вы путаете коммерские проекты с коммерческим ПО. Есть определенные причины, по которым многие компании и организации предпочитают покупать коммерческие варианты PostrgeSQL или MySQL. Но обе СУБД могут использоваться бесплатно в коммерческих проектах, если не нужны дополнительно разработанные коммерческие дополнения и нет потребности в техподдержке от непосредственного разработчика. Однако, если с PostgreSQL все понятно (свободна и бесплатна), то с MySQL начались сложности сразу после ее поглощения Sun корпорацией Oracle. Теперь, чтобы разобраться в том, что можно и что нельзя, нужно внимательно прочитать специальный лицензионный справочник, размером с хорошую книгу, и учесть все нюансы и хитросплетения, которые Oracle наплела. Поэтому многие предпочитают отказываться от MySQL в пользу MariaDB.

Ваша оценка: Нет
pomodor

Иногда просто удивляться приходится откуда берется такая информация. Это искренне или это троллинг такой?

Это реальность наших дней. Эксперды новой формации.

Ваша оценка: Нет

Странный народ. Есть Windows 7 Enterprise и Windows 10 Entererise LTSB. Вторая ОС просто идеальна. За невежество и глупость надо наказывать, увольнять.

Ваша оценка: Нет Средняя оценка: 3 (4 votes)
reflexius

Выбор открытых программных систем — это вопрос не только и не столько производительности или удобства. Сегодня это вопрос безопасности и предсказуемости. И особенно в организациях государственной инфраструктуры. Сколько нужно доказательство того, что Microsoft не брезгует шпионажем, чтобы выбрать между открытым и закрытым ПО? Какой смысл покупать более дорогие лицензии на закрытую Windows, если с тем же или большим успехом задачи могут быть решены менее затратными и открытыми системами? Поэтому Вашу фразу "за невежество и глупость надо наказывать, увольнять" я бы вернул Вам и тем чиновникам и менеджерам, которые тратят деньги налогоплательщиков почем зря.

Ваша оценка: Нет Средняя оценка: 5 (4 votes)

Кто бы спорил. Беда в том, что свободные дистрибутивы Линукс говённого качества. То звук, то негодные драйвера на видеокарту, то процессор греется.

Ваша оценка: Нет Средняя оценка: 1.8 (5 votes)

Чем больше организаций и структур будут переходить на линь, тем выше заинтересованность в отточенной работоспособности => линь улучшается.

Ваша оценка: Нет Средняя оценка: 4 (4 votes)
pomodor

Не надо вестись на агитацию анальщиков Микрософта. Linux прекрасен. Да — не для игр. Ну и хер с ними. В остальном все отлично.

Ваша оценка: Нет Средняя оценка: 4.5 (4 votes)
Texnoline

Особенно, коммерсы и госсы! Вот тогда все и завертится, а пока только на голом..., в этой стране;)

Ваша оценка: Нет
Texnoline

Беда в том, что свободные дистрибутивы Линукс говённого качества

ага, а в NASA, AT&T, и в других компаниях подобного уровня, используют только говенный софт! Карл, ты в это веришь!?

То звук, то негодные драйвера на видеокарту, то процессор греется.

проблема производителя железа или драйвера, а затем пользователя, при его ошибках в выборе нормального железа, чтобы и дрова были и не грелось!

Ваша оценка: Нет
Отправить комментарий
КАПЧА
Вы человек? Подсказка: зарегистрируйтесь, чтобы этот вопрос больше никогда не возникал. Кстати, анонимные ссылки запрещены.
CAPTCHA на основе изображений
Enter the characters shown in the image.