PostgreSQL vs MySQL

Странно, я ведь упомянул преимущества MySQL — более простое администрирование, как минимум…

Postgres расправляет плечи

Если вы описали непересекаемость занятий в расписании как constraint, и меняете их в одной транзакции — то почти никаких, вот эту штуку только передёрнуть в начале транзакции www.postgresql.org/docs/9.3/static/sql-set-constraints.html

Postgres расправляет плечи

Не бизнес-логика в СУБД, а корректное описание типов в СУБД.
Корректность и консистентность данных — это как беременность, либо она есть, либо её нет.

Если не описывать «что такое консистентные данные» на уровне схемы базы, то вам придётся описывать это на уровне приложения, и в каждой точке где вы загружаете что-то из базы делать проверки.

Вы правда хотите проверять всё-всё вручную? Конечно, есть ситуации, когда проще проверять в приложении — например, когда нужно проверить статус чего-либо во внешней системе, но 99% проверок можно унести на уровень СУБД и рассматривать это как простой и гибкий валидатор ваших данных (и, к тому же, очень быстрый)

Доставка обновлений из БД MySQL в приложение при помощи клиента репликации libslave

Для фильтрации на стороне мастера одной базы вам поможет:
--binlog-ignore-db

Для фильтрации таблиц — сделайте промежуточный mysql-slave, в нём поставьте опции
--replicate-ignore-table

и уже со slave высасывайте libslave обновления

Несколько различных VPN подключений с локальными DNS серверами

Спасибо.
Разберусь с dnsmasq, напишу второй пост — как тоже самое делается через dnsmasq

Несколько различных VPN подключений с локальными DNS серверами

На my.domain стоит именно dnsmasq.
Но как он поможет на моём ноутбуке?
Опишите конфиг/настройку для моего случая

Проблемы MySQL оптимизатора

Разве что так. Только это немало работы.

Проблемы MySQL оптимизатора

bugs.mysql.com/bug.php?id=68697

Проблемы MySQL оптимизатора

> Я не поняла каким образом storage engine API не даёт сделать

Нету такой функции в API, чтобы unique cardinality узнать

> Если это в самом деле так, откройте bug report, пожалуйста.

Файл storage/innobase/handler/ha_innodb.c

innodb_rec_per_key(
...
{
	ha_rows		rec_per_key;

....
			rec_per_key = (ha_rows)(
				(records - num_null)
				/ (index->stat_n_diff_key_vals[i + 1]
				   - num_null));
		}
	} else {
		rec_per_key = (ha_rows)
			 (records / index->stat_n_diff_key_vals[i + 1]);
	}

	return(rec_per_key);
}

./include/my_base.h:typedef ulong		ha_rows;

Проблемы MySQL оптимизатора

> И ещё вопрос к автору. Не в курсе ли ты, TokuDB сделали только storage engine, или ядро они тоже исправляли?

Первый раз про неё слышу, потому ничего не могу сказать.

Проблемы MySQL оптимизатора

> Что мешает поступить так? (

То, что весь код заточен на сложившуюся архитектуру.
Начинать переделывать этот аспект — придётся много чего трогать, а там уже тоже проблем накопилсь, и не факт, что они менее важны, чем описываемые мною.

> (Ещё хотел бы добавить, что если вы вдруг будете делать что-то с внутренностями mysql и попытаетесь искать помощи в mailing list, то во-первых подтверждения я ждал больше суток, а во-вторых, когда меня туда включили, мой вопрос всё равно проигнорировали. Ну то есть даже никакого «go away, you moron» не было, вообще ничего)

Да, изучать внутренности может получится лишь двумя способами
1) Пообщаться с человеком, что занимается разработкой
2) Читать сорцы.

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

Проблемы MySQL оптимизатора

Используемых — порядка двадцати (суммарно).
А как вы определяете, какие сторонние, какие нет?
Вот XtraDB — сторонний?

Проблемы MySQL оптимизатора

Прочитайте пост. Это API сломано. Все storage engine, by degisn.

Проблемы MySQL оптимизатора

Когда вы вызываете mysql_query(), вы зовёте код, который зовёт внешние (относительно MySQL) storage engine.
unique row count добавить в API просто
Починить NULL'ы — это архитектурная переделка оптимизатора и индексов во всех storage engine.

Я в посте недостаточно правильно выразился.
Проблема не только в API как таковом, но и в том, как под него заточен оптимизатор и engines.

Проблемы MySQL оптимизатора

Тогда это будет новый продукт, просто с тем же именем.

Проблемы MySQL оптимизатора

Drizzle… У него куча других проблем.
Не смотрел, но не думаю, что они решали проблемы описанные в посте.
У них другие цели.

Проблемы MySQL оптимизатора

А что, в «нормально» спроективрованных БД не нужны outer join'ы?
Или подзапросы не используются?

Проблемы MySQL оптимизатора

> Как я понял, речь о внутренних интерфейсах. Если синтаксис останется прежним, то подавляющее большинство юзеров (админов и разработчиков) ничего не заметят

Неверно. Сломанный Storage Engine API == переделка всех storage engine.
Многой информации там просто нету.
Например, Merge Engine — я вижу проблемы в реализации новых функций.
С другими тоже непросто — те же индексы в InnoDB придётся _существенно_ переделывать.

В общем, там кругами по воде будет расходиться.

> Весьма спорно. Даже если синтаксис запросов и/или внешних API изменится незначительно. Инерция очень велика.

Storage Engine API — внешнее.

Проблемы MySQL оптимизатора

Я давно не общался с разработчиками MariaDB, но если кто и перепишет оптимизатор — так это они.
Но это будет уже не совсем MySQL.
Про проблемы эти они знают.