Московская биржа выбирает 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 тыс. биржевых заявок каждый день. И делает это настолько хорошо, что Урожай уже получил почетную премию за лучшее «облачное решение года».

field_vote: 
Ваша оценка: Нет Средняя: 5 (7 оценки)
Дистрибутивы: 

Комментарии

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

Оценка: 
Пока без оценки

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

Оценка: 
Средняя: 5 (5 оценки)

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

Оценка: 
Средняя: 4 (1 оценка)

Если 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 тоже.

Оценка: 
Пока без оценки

Умом выбор 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 оценки)

Чой это? 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 оценки)

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

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

Оценка: 
Средняя: 5 (1 оценка)

Согласен на 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, а остальные держать на диске.

Оценка: 
Пока без оценки

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

Оценка: 
Средняя: 5 (2 оценки)

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

Оценка: 
Пока без оценки

Про 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.

Оценка: 
Пока без оценки

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

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

Оценка: 
Пока без оценки

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

Оценка: 
Средняя: 3 (4 оценки)

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

Оценка: 
Средняя: 5 (4 оценки)

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

Оценка: 
Средняя: 1.8 (5 оценки)

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

Оценка: 
Средняя: 4 (4 оценки)

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

Оценка: 
Средняя: 4.5 (4 оценки)

Комментировать

Filtered HTML

  • Use [fn]...[/fn] (or <fn>...</fn>) to insert automatically numbered footnotes.
  • Доступны HTML теги: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote> <strike> <code> <h2> <h3> <h4> <h5> <del> <img>
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Строки и параграфы переносятся автоматически.

Plain text

  • HTML-теги не обрабатываются и показываются как обычный текст
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Строки и параграфы переносятся автоматически.