Разработчики СУБД MariaDB анонсировали (http://blog.mariadb.org/announcing-the-cassandra-storage-engine/) новое хранилище Cassandra Storage Engine (https://kb.askmonty.org/en/cassandra-storage-engine/) (SE), добавляющее в MariaDB и MySQL поддержку средств для доступа к данным, хранимым в распределённой БД Apache Cassandra (http://www.opennet.me/opennews/art.shtml?num=33676). Используя Cassandra SE разработчики получают возможность обращаться к данным и добавлять данные в БД Cassandra при помощи обычных SQL-запросов. При этом используемая в Cassandra модель хранения данных в виде семейства столбцов (ColumnFamily) отображается в форме свойственных для MariaDB/MySQL таблиц, для которых можно применять стандартные SQL-директивы SELECT, INSERT, DELETE и UPDATE, а также выполнять операции объединения (JOIN) с другими таблицами.
Кроме того, выпущены очередные корректирующие релизы MySQL - 5.5.28 (http://permalink.gmane.org/gmane.comp.db.mysql.announce/681) и 5.1.66 (http://permalink.gmane.org/gmane.comp.db.mysql.announce/683), а также MySQL 5.6.7 (http://permalink.gmane.org/gmane.comp.db.mysql.announce/682) - первый кандидат в релизы для находящейся в процессе стабилизации ветки MySQL 5.6 (http://www.opennet.me/opennews/art.shtml?num=31291). В MySQL 5.1.66 представлено два изменения (изменение внутреннего интерфейса плагинов для работы с пулом тредов и портирование некоторых полей со статистикой из ветки 5.6) и 15 исправлений ошибок, среди которых мог наблюдаться крах клиентского приложения при его одновременном связывании с libmysqlclient_r и libcurl, крах mysqlhotcopy при работе с БД, содержащей представления, и крах рабочего процесса при выполнении "CHECK TABLE" и "REPAIR TABLE" в случае различных описаний ключа MyISAM-таблицы в файлах .frm и .MYI.
Что касается MySQL 5.6.7, то отмечается (http://dev.mysql.com/tech-resources/articles/mysql-5.6-rc.html) значительная работа по расширению возможности и увеличению производительности движка InnoDB, в котором появилась поддержка полнотекстового поиска и ряд значительных оптимизаций, по сравнению с веткой 5.5 позволяющих в некоторых случаях увеличить производительность транзакций, связанных с чтением данных в два раза, а с записью до четырёх раз.
В заключение можно упомянуть заметку (http://blogs.computerworlduk.com/simon-says/2012/09/oracle-c...) Саймона Фиппса (Simon Phipps), ранее руководившего направлением open source в компании Sun Microsystem, а ныне входящим в управляющий совет организации Open Source Initiative (OSI), с пояснение причин недавнего исключения (http://www.opennet.me/opennews/art.shtml?num=34607) из состава общедоступного архива с кодом MySQL набора тестов для проверки исправляемых ошибок и добавляемых новшеств. По сведениям одного из работников Oracle, имя которого не называется из-за опасения обвинения его в разглашении внутрикорпоративной информации, публикация указанных компонентов в открытом доступе прекращена по требованию службы безопасности Oracle, которая выявила, что связанные с проблемами безопасности тесты используются в роли готового прототипа для создания эксплоитов на ранней стадии выхода релизов (эксплоит появляется раньше, чем корпоративные клиенты успевают установить плановое обновление Enterprise-версии MySQL). Попытки разработчиков MySQL наладить прозрачное взаимодействие с сообществом натолкнулись на непробиваемую корпоративную политику, которая даже не дала возможность публично объяснить причину прекращения публикации тестов. В будущем планируется продолжить публикацию тестов, но с ограничениями для ошибок, затрагивающих GA-выпуски (http://www.mysql.com/downloads/).
URL: http://blog.mariadb.org/announcing-the-cassandra-storage-engine/
Новость: http://www.opennet.me/opennews/art.shtml?num=34980
> натолкнулись на непробиваемую корпоративную политику,А потом проприерасы искренне удивляются когда узнают что их за что-то оказывается не любят.
иллюзии, никто ничему не удивляется
а потом хомячки удивляются - чего это у них поломали кучу серверов, а оно оказывается что проект распространял готовые эксплойты...
Проект который так делает - надо мочить в ранней стадии, нефик облегчать работу взломщикам.
Да. Давайте сделаем кривые ключи зажигания для автомобилей. Это ведь сильно затруднит работу угонщиков. Ой, а что это водители на нас теперь вдруг так косо смотрят?
Эх... Школота...
Давайте будем оставлять машины не закрытыми. Только не будем удивляться что кто то взял "покататься"
простите, но в новости -- автомобили так и оставили открытыми. только теперь ввели политику молчания об этом (и как побочный эффект -- молчания о том в каком месте встроенный GPS показывет дорогу не туда)
Я бы сказал что сейчас спрятали кнопку включения - хотя да, формально автомобиль открыт - но кнопку включения надо еще поискать (вы же не протестуете что кнопку отключения сигнализации в автомобилях прячут по возможности далеко?).Другими словами.
Сейчас что бы сделать эксплойт надо изучить код и найти это.
В случае готового варианта - просто взять и применить стандартные механизмы или изучить точно - ровно одно место.Я думаю вы сами понимаете что займет меньше времени? Или еще надо объяснять?
MariaDB молодцы .... Cassandra вкусная штука, вот только интеграция "в лоб" - дело накладное. А тут такая радость ...
А от этих вкусностей что-то остаётся при работе через SQL-прокладку?
Кластеризация, автоматическая репликация и возможность наращивать кластер хранения без остановки останутся даже при наличии SQL-доступа. Значит сохранятся все преимущества хранения. И добавится SQL.Огромный плюс этим джентльменам за то, что теперь обычные приложения заточенные на SQL можно запускать поверх отказоустойчивого хранилища.
а кто как думает -- как будет вести себя система данных -- если:к одному кластеру Кассандры -- прикреплено несколько SQL-оболочек?
как в этом случае -- будет ли обеспечиваться непротиворечивость данных?
(возможно что даже -- хорошо. мне просто интересно)
> к одному кластеру Кассандры -- прикреплено несколько SQL-оболочек?
> как в этом случае -- будет ли обеспечиваться непротиворечивость данных?
> (возможно что даже -- хорошо. мне просто интересно)Все так или иначе преобразуется в данные Cassandra.
Вопрос в механизмах преобразования, то есть вопрос в механизме трансляции SQL->CQL
Надо брать реализации и смотреть ...
> а кто как думает -- как будет вести себя система данных --
> если:
> к одному кластеру Кассандры -- прикреплено несколько SQL-оболочек?
> как в этом случае -- будет ли обеспечиваться непротиворечивость данных?
> (возможно что даже -- хорошо. мне просто интересно)отлично - примерно также как работает NDB когда к нему прицеплено несколько SQL-нод
Если SQL-оболочки будут работать в режиме "ConsistencyLevel ALL", то непротиворечивость будет обеспечена тем, что SQL-транзакция будет висеть пока не получит подтверждение от Cassandra-кластера, который выдаст ответ когда ВСЕ ноды содержащие изменяемые данные выдадут подтверждение транзакции.
Что еще интереснее можно писать в ConsistencyLevel ALL, тогда читать в ConsistencyLevel ONE и будет полная консистентность. Быстро читаем, но долго пишем.
Либо писать в режиме ConsistencyLevel ONE, а читать в ConsistencyLevel ALL. Тогда опять же данные консистентны, но долго читаем и быстро пишем.Для веба же (где часто применяется MySQL) консистентность не является принципиально важной - достаточно Eventual consistency. Eventual consistency это подход, когда консистентность гарантируется спустя конечный период времени. Пример: в конташечке Вася написал Маше сообщение, через секунду Маша проверила входящие, но сообщения еще не пришло. Проверив почту через 5 секунд Маша получила сообщение. Для Веба это подходит ;)
прочитал https://kb.askmonty.org/en/cassandra-storage-engine/ .. всё именно так!но это же какое то волшебство тогда!
(тяжёлая магия от MariaDB)
YAW ;)
>теперь обычные приложения заточенные на SQL можно запускать поверх отказоустойчивого хранилища.Ну тут нужно иметь ввиду производительность.
Эффективность индексов в этих бд различна, там где sql бд выполнит запрос сразу, в кассандре может выполняться долго.Обычно структуру таблиц и colum family проектируют по разному, и прямой маппинг не всегда эффективен.