Собственно сабж.

Существует ли какой-то движок, форк или версия mysql, в которой добавление колонки не будет требовать пересоздание или перезаписывание по месту всей таблицы?
Гуглеж искомого не дал. Даже после всех нововведений 5.6 добавление колонки все равно требует огромного числа дисковых операций.

Мда, спецы еще те.

Фича найдена в tokudb

http://www.tokutek.com/tokudb-for-mysql/


Hot Column Addition/Deletion/Rename allows administrators to rapidly define and add new fields

miksoftnolocky,

Если Вам актуальны Hot Column Addition, то зачем вообще брать MySQL?

Хотя за ссылку спасибо.
я его и не беру, я пока оцениваю его пригодность к продукционному использованию. и изучаю типовые сценарии его применения.


все что я вижу сейчас - это то, что в виду невозможности добавлять колонки в сколько-то больших базах данных единственный паттерн применения MySQL из коробки - это EAV, вернее key-value, где value это e-blob (json, к примеру, или xml).
как это делает facebook.

или сверхмелкие базы данных, до миллиона записей на таблицу (типовые сайты-бложики), где добавление одной колонки не будет отправлять сайт в многочасовую недоступность

что довольно странно, уже вроде не первый год серверу, а такие простейшие вопросы, как добавление колонки - не могут решить

miksoftMySQL в последние годы много времени потратил на смену собственников. Отчего, собственно, и стали так активно расти форки.

Не убедительно. Моментальный ADD COLUMN во всех других базах данных (коммерческих, или изначально коммерческих, вроде Interbase) был доступен изначально, еще с 80-х годов.

А тут - нет. Даже в sqlite ADD COLUMN не требует пережевывания всей таблицы, собственно mysql - это единственная SQL база, где я такое увидел, и это было сильно неожиданно.

miksoftТак что не не берите MySQL, не надо :)

Мне его в любом случае придется брать на попробовать, для написания своего engine прямого доступа в nosql базу (для реализации newsql, в кластерной среде - локальный mysql будет стоять на каждой ноде и смотреть сразу в локальную nosql lmdb).

В других серверах БД возможности написать свой engine относительно дешево пока не замечено.
Хотя еще есть шанс custom ODBC driver, но то такое, кластер из этого точно не собрать.

nolockyХотя еще есть шанс custom ODBC driver, но то такое, кластер из этого точно не собрать.

Хотя скорее всего это будет просто собственная R/O FUSE файловая система, которая будет предоставлять таблицы в виде .csv псевдо файлов, которые уже будет читать Oracle XE как EXTERNAL TABLE через даталинки и отдавать в аналитику в привычном для всех виде.

Но... у MySQL еще есть шанс нас убедить своим перфомансом на SELECT из кастомного ENGINE. Или из родного CSV

MasterZivnolockyпропущено...

я его и не беру, я пока оцениваю его пригодность к продукционному использованию. и изучаю типовые сценарии его применения.ну, не самая лучшая СУБД в мире, да.

но и добавление колонки в бд не самая ходовая операция. в бд обычно структура не меняется после окончания разработки приложения.

nolockyчто довольно странно, уже вроде не первый год серверу, а такие простейшие вопросы, как добавление колонки - не могут решитьеще раз, это мало кому нужно.

не надо рассказывать сказки, 90% всех изменений в потрелизных патчах - это расширение схемы - новые таблицы и колонки


просто на микроскопически базенках сайтов визиток этот косяк - пережевывание таблицы при добавлении колонки - никто еще не заметил


а фейсбучек с этой проблемой столкнулся уже на третьей итерации и перешел на еблобы EAV, превратив субд в неструктированный сторидж

javajdbcnolocky...
а фейсбучек с этой проблемой столкнулся уже на третьей итерации и перешел на еблобы EAV, превратив субд в неструктированный сторидж


Приведите , пожалуйста ссылку.

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

Оказа от релейшнл основы МыСКЛ я не нашел.

Вот одна из.

http://www.insight-it.ru/masshtabiruemost/arkhitektura-facebook/ MySQL — используется как хранилище пар ключ-значение, никаких join'ов

Вот вторая, страница 10

http://www.slideshare.net/mysqlops/facebook-architecture MySQL user primarily as <key,value> store

Думаю достаточно ссылок?

Вот тут их главный инженер вещает о всей поднаготной: http://www.infoq.com/presentations/Scale-at-Facebook

на 30:25 начинается про базы данных, а на 30:50 откровение прямым текстом - только key/value store, никаких джойнов, оптимайзеров и вообще какой-либо реляционной херни, только EAV, только хардкор!

там слайдик будет справа

javajdbcnolocky,

Ок, понятно, но они в постоянном поиске:

грамчик посвежее (214 против 2011) информация:
http://www.percona.com/blog/2014/03/27/a-conversation-with-5-facebook-mysql-gurus/

Вкратце:

1. Фейсбук все еше сильно используер
мусял в базовом -- релятивистком смысле.

2. только малая часть -- в основном важные апдейты, идут
напрямую в базу. боьшинство чтения и
временые (сессионные) апдейты идут в/из промежуточные
слои -- CDN, memcache, etc.

3. они реально улучшают кишки мыскл-а

4. Шардинг


НАсчет блобов -- это скорее как один из варинатов,
но не основной.

как такая компания, как фейсбук - с их петабайтами данных, да еще и застрявшая на mysql 5.0 (сильно дописанном вручную) может в здравом уме работать в реляционной модели, если каждое банальное добавление колонки потребует тупо переписывания всего объема этих петабайт, 98% из которых - и вовсе "мертвые" данные - фоточки и коменсты более годовой давности, которые уже никогда никому не понадобятся?



кроме того, речь шла про основные сервисы фейсбука, а вот тут: http://www.percona.com/blog/2014/03/27/a-conversation-with-5-facebook-mysql-gurus/ описывается всякая мелочевка вспомогательная, компания большая, и применение имеется всякое, ктобы спорил

но меня не интересует вспомогалово, мне интересны лишь ключевые технологии.

а в вот в ключевых технологиях - тупо key-value, причем value - это именно JSONовский eblob, потому что скорость! или одним хопом достаем все, или делем сотни запросов, разницу, думаю, пояснять не нужно.

а про memcache рассказывать не надо, не интересно

Модератор: Замечание. Прошу вести диалог в более культурной форме. Общение в стилистике ПТ здесь категорически не приветствуется.