Facebook анонсировал (https://code.facebook.com/posts/1474977139392436/webscalesql.../) проект WebScaleSQL (http://webscalesql.org/), в рамках которого подготовлена редакция MySQL 5.6 для использования в крупных web-проектах. WebScaleSQL является совместной разработкой компаний Facebook, Google, LinkedIn и Twitter, инженеры которых договорились объединить свои усилия в области оптимизации производительности и масштабируемости MySQL. При этом, WebScaleSQL не является форком MySQL, а представляет собой надстройку над основной кодовой базой Community-версии штатного MySQL от компании Oracle. Все наработки WebScaleSQL распространяются (https://github.com/webscalesql/webscalesql-5.6) под лицензией GPLv2.
В качестве причины создания отдельного варианта MySQL, вместо развития таких проектов, как MariaDB, Percona Server и Drizzle, называется наличие в MySQL 5.6 пригодных для промышленного использования возможностей, достаточных для развития в качестве отправной точки. Тем не менее, по мере развития экосистемы, будет приниматься во внимание возможность задействования альтернативных решений. В WebScaleSQL воедино собраны внутренние патчи, применяемые в Facebook, Google, LinkedIn и Twitter, поэтому в качестве отправной точки для слияния разработок стало использование основной кодовой базы MySQL.
Переход к совместной разработке позволит избавиться от выполнения дублирования работы в каждой из компаний-участников проекта, упростит процесс разработки новых возможностей и увеличит эффективность тестирования. Вместо параллельного развития близкой по своей сути функциональности, в рамках WebScaleSQL будет поддерживаться наиболее эффективный вариант. Кроме того, так как больше людей будут заниматься аудитом изменений, ожидается увеличение качества и надёжности кода.
Из дополнительных возможностей WebScaleSQL отмечается:
- Автоматизированный фреймворк для проверки всех изменений с использованием встроенной системы тестирования MySQL;
- Новый набор (https://github.com/webscalesql/webscalesql-5.6/commit/8b6adf...) для автоматизированного стресс-тестирования и оценки производительности;
- Серия изменений к оригинальному тестовому набору и структурам MySQL, направленных на обеспечение внесения безопасных изменений, которые раньше приводили к сбоям выполнения тестов или конфликтам;
- Серия улучшения для повышения производительности, включая улучшение механизма чистки пула буферов, дополнительные оптимизации некоторых типов (https://github.com/webscalesql/webscalesql-5.6/commit/d72b58...) запросов и поддержку (https://github.com/webscalesql/webscalesql-5.6/commit/175520...) политики чередования для NUMA;
- Новые возможности для упрощения применения в высоко масштабируемых системах. Например, режим super_read_only (https://github.com/webscalesql/webscalesql-5.6/commit/414209...) и возможность (https://github.com/webscalesql/webscalesql-5.6/commit/c1d98e...) определения таймаутов на уровне долей секунды.
Из ещё не добавленных в WebScaleSQL возможностей, над которыми ведётся работа, отмечены:
- Вариант MySQL-клиента, работающий в асинхронном режиме, что позволяет в процессе запроса MySQL не дожидаться завершения установки соединения, отправки и приёма данных;
- Поддержка дополнительной статистики для таблиц, пользователей и сжатию данных;
- Используемая в Facebook реализация системы сжатия хранимых данных;
- Логический механизм упреждающего чтения (Read-Ahead), позволяющий заметно увеличить производительность (до 10 раз) операций последовательного полного перебора данных в таблицах, например, в процессе выполнения резервного копирования.
URL: https://code.facebook.com/posts/1474977139392436/webscalesql.../
Новость: http://www.opennet.me/opennews/art.shtml?num=39425
Ждём всё это в MariaDB, хрен ли там.
Да, ты прав. Хрен форкам. MySQL forever!
MariaDB должна быть совместима с MySQL, потому эта надстройка должна запуститься и на Maria.ИМХО MySQL взят потому как с ним все работали. После синхронизации сменят на что-то активно развивающееся.
> MariaDB должна быть совместима с MySQLНикому MariaDB ничего не должна. Но ты прав -- если патчи годные, не грех их принять в MariaDB.
>совместной разработкой компаний Facebook, Google, LinkedIn и Twitter, инженеры которых договорились объединить свои усилияИ правильно сделали, всем бы так.
>> инженеры которых договорились объединить свои усилия
>И правильно сделали, всем бы так.святая наивность ;)
договорились те, кто платит ЗП этим инженерам. а инженеры побежали и сделали.
> договорились те, кто платит ЗП этим инженерам. а инженеры побежали и сделали.раб — наподобие тебя — в принципе не способен представить, что работодатель не Барин. если *тебе* прикажут — ты, без сомнения, побежишь и сделаешь. а потом будешь заглядывать в глаза: доволен ли Хозяин?
вы, рабы, удобные существа — но в делах, где требуется разум, бесполезные: вам намного важнее не то, что надо сделать, а то, как оценит это Хозяин.
вот поэтому ты и не понимаешь того, что если бы инженеры не захотели, то ничего бы не получилось. а то, что хотелки работодатели ещё и оплатили — это вообще здорово.
> если бы инженеры не захотели, то ничего бы не получилосьахахахахах, прекрати :)))
у тебя истерика? бедняжка. попей таблеточек.
Код то открытый, так что вполне могли договориться инженеры чтобы быстрее и лучше.
Фантастический союз, конечно, но где хоть какие-то тесты?
> Фантастический союз, конечно, но где хоть какие-то тесты?Зарегся в фб, да потести. Иногда подглючивает, даж невооруженным взглядом видно.
А зачем, у них работает, они собрали вместе свои труды, выложили, может кому пригодиться, за одно и со стороны проверят, поправят, доработают.
Шел 2014 год. Но лицокнига упорно продолжала насиловать похапэ-мускуль.
Попробовав раз, ем и сейчас.
А что делать? Переделывать все огромные риски. Переучивать такого уровня специалистов нереально, они сами должны переучиваться. А если они будут переучиваться кто будет писать функционал. Так что так и будут теперь, пока смерть не разлучит их
Бедный "крутой энтепрайз программист" остался в жопэ со своим джава. Печалька. Ему приходится теперь заклинать про 2014 год. Лицекнига, помоги горю! Перейди на джавэ!
Простите любезный, а вы что используете?
дак это ж дотнетчик или жаво-петопе-пеглист, я почти уверен в этом
Аноним в моем лице полагает, что LAMP в настоящее время - оптимальное решение.
Лампа оптимальна для небольших/средних по нагруженности проектов. (Это эмпирический вывод)
Для сильно нагруженных проектов лучше всего что-то типа эрлангов и ноуЭсКьюЭльей. (Это уже теория анонимуса в лице меня)
И теории-теориями, однако факт того, что мордокниги и прочие втентакли вечно чем-то пытаются допилить/перепилить пыхи и мускули недвусмысленно говорит о том, что стандартная лампа явно не оптимальна для них, просто они не хотят ломать совместимость с имеющейся кодовой базой.
На эрлангах пишут внутренние сервисы. Вебморду писать на эрланге - это увеличить стоимость ее разработки на порядок (столько специалистов на рынке просто нет и они дорогие).NoSQL-и тоже используются как хранилище для определенных сервисов, где с mysql-ем никуда. Но для задач типа "сохранить профайл пользователя" mysql с шардированием подходит прекрасно, а в узких местах можно использовать handlersocket. Конечно, сейчас, в 2014 году, есть серьезные подходящие для продакшена nosql-решения, но смигрировать все данные того же фейсбука - просто нереально.
> Вебморду писать на эрланге - это увеличить стоимость ее разработки на порядок (столько специалистов на рынке просто нет и они дорогие).те, кто сделали зотоник об этом, похоже, не знали.
Исключение, которое подтверждает правило.
>> Вебморду писать на эрланге - это увеличить стоимость ее разработки на порядок (столько специалистов на рынке просто нет и они дорогие).
> те, кто сделали зотоник об этом, похоже, не знали.Скорее всего знали, но это не меняет дело.
Есть и на перле CMSки.
Вы попробуйте на hh.ru найти пару десятков миддлов/сеньоров программистов на php, и пару десятков миддлов/сеньоров программистов на erlang.
Ну и зарплаты посмотрите.
Но это только начало.
Потом попробуйте сравнить средства разработки, тестирования, continuos integration и т.д. для php и erlang.
Плюс объем документации и количество коммьюнити.
Это скажется на стоимости вырастания программистов (джуниоров-> миддлов и дальше).
Потом посмотрите количество вспомогательных инструментов (аналитика, рассылки, интеграция других решений в свой продукт), которые есть для php, и которые есть для erlang.
В конце концов оценочная себестоимость (по деньгам и времени) будет различаться на порядки.
Перепишу за неделю на ерланге! $2000
> Перепишу за неделю на ерланге! $2000ок. давай бабло и садись писать.
Совпало с анонсом InfiniDB http://www.digitaljournal.com/pr/1813332
что только не делают, чтобы не мигрировать на распределенные и масштабируемые(не только в плане перформанса)БД !!
впервые можно таки-использовать в уничижительном смысле "индус" применительно к програламерами фэйсбук. увы и ах.
то-же с пэхэпэ и прочми.
когда их "домашняя страничка" разрослась - они не стали ее переделывать, нет. они купили мощные серверА и прикрутили костылей к велосипеду, на котором он ездил ранее.
> что только не делают, чтобы не мигрировать на распределенные и масштабируемые(не только
> в плане перформанса)БД !!Может им не надо возможности масштабировать до масштабов галлактики, может им земли достаточно, и при этом чтобы быстро/надёжно на одну планету и без проб и ошибок ;)
> впервые можно таки-использовать в уничижительном смысле "индус" применительно к програламерами
> фэйсбук. увы и ах.
> то-же с пэхэпэ и прочми.
> когда их "домашняя страничка" разрослась - они не стали ее переделывать, нет.
> они купили мощные серверА и прикрутили костылей к велосипеду, на котором
> он ездил ранее.Ну так в этом наверное и есть ключевое отличие между быстрорастущим бизнесом и академической работой ;)
что характерно: эти «индусы» продолжают зашибать бабло, а ты — весь такой умный — в лучшем случае вкалываешь на дядю и имеешь ипотеку с ведром болтов в кредит.
А можно нам, позорным лохам, примеры «распределенных» и «масштабируемых»?Cassandra, Hbase, Hypertable, — знаем-знаем, толку что они есть, если монолитным решением как таковым быть не могут.
То, что вы все любители острой мысли — это хорошо и одновременно плохо: разные мысли бывают, несостоятельного и сомнительного характера больше.
> монолитным решением как таковым быть не могут.нас посетил представитель Кровавого Энтерпрайза?
Oracle теперь посмотрит в исходный код WebScaleSQL и перетащит все идеи в свою СУБД oracle :)