Это большой будет патч, но можно сделать. Я делал что-то подобное в проекте foreign keys for all storage engines, в MariaDB сейчас на этот счёт что-то делается, насколько я знаю.
В первую очередь этот патч добавляет поддержку детектора дедлоков в user level lockи, что полезно если они используются в любых нетривиальных сценариях.
А в остальном, думаю надо разбираться по ситуации, скорее всего это связано как-то с управлением задачами или очередями — когда нужно исключить возможность одновременной работы двух или более клиентов, выполнить какую-то нетривиальную синхронизацию.
Не могу не удивиться глупости инвесторов:
— выкидывать на рынок решение с закрытым исходным кодом
— нарушать GPL
— основывать архитектуру in-memory database на основе кода MySQL, Которому 15 лет и который *не айс*, как по качеству кода так и по архитектурным решениям.
Я, конечно, человек ангажированный, но всё это похоже на какую-то разводку (с)
По-моему, очень странное решение — гиперпространственное хэширование. Подходит для узкого круга задач (когда нужно уметь быстро искать по любому атрибуту). При этом, т.к. это хэширование, то нельзя делать JOIN по диапазону нескольких атрибутов эффективно (т.е. получить, скажем, все марки автомобилей на рынке с колёсной базой в дипапазоне от 2.5 до 2.7 м и ценой в диапазоне от 750 до 900 тысяч). То есть, хочу быть понят правильно, в Редис этого тоже нельзя, но если индексирование изначально заявлено как *многомерное* то именно такие запросы, на мой взгляд, интересны.
Сравнение в этом ключе со всеми остальными базами мне кажется мало уместным, т.к. у конкурентов будет профиль по потреблению памяти совсем другой (индексы по каждому атрибуту таки требуют памяти).
Интересно, что они при этом сразу сделали кластер. Их кластерное решение мне кажется любопытным, т.к. они обеспечивают атомарность за счёт записи изменений на несколько узлов кластера. Это правильно, быстрее чем диск, так поступает NDBCluster. Но и памяти это потребляет, по моим представлениям, соответственно.
Всё что происходит очень похоже на способ маркетинга стартапа, т.к сразу готов сайт, бенчмарки, списки рассылки и т.п., о преимуществах они говорят, а о недостатках и ограничениях предоставляют сообществу сделать вывод самостоятельно.
Возможно, я не прав в своих оценках, т.к. потратил на продукт только 30 минут и ушёл пилить Tarantool.
Open Source мир так не живёт, community строится не сразу, особенно в такой насыщенной поляне как NoSQL.
1) Балансировка данных в бинарных деревьях, то есть индексах по данным, автоматическая.
2) Балансировка каждый раз частичная, проблем с доступностью не возникает.
3) Этого как раз нет, я пытался чётко отписаться, что данные между узлами тарантула мы автоматически балансировать не умеем.
POSIX threads требую использования механизмов синхронизации при доступе к общим данным.
Т.к. каждый запрос мал, то издержки на эти механизмы будут сравнимы с издержками на всё выполнение запроса. Т.е. для этой задачи POSIX threads получаются слишком тяжеловесны.
Моя позиция: С++ очен плохо совместим с C, т.к. требует RAII. В Objective C есть клауза @finally, что позволяет совмещать наличие исключений и обычный код на С, в котором нет авто-деструкторов.
С++ опасен так же тем, что на нём очень легко писать плохие программы — слишком много способов использовать механизмы языка неправильно.
Кроме того, за счёт богатства языка, при работе в команде очень много времени уходит на утряску единого стиля программирования, выработку общих соглашений об использовании или неиспользовании средств языка.
Я не вижу здесь перебора. Открыли индекс. Читаем в порядке от меньшего к большему. Пока есть кортежи с ключём меньше заданного, мы их удалям. Так же как делает любая СУБД. Перебор был бы если бы мы бежали по всем кортежам, сравнивали бы в них поле last_activity с заданным, и удаляли. Мы же идём по индексу и останавливаемся как только нашли первый неподходящий.
На Луа это будет выглядеть примерно так:
oldest_tuple = box.space[0].index[1]:min()
while oldest_tuple[1] < 123456 do
box.space[0]:delete(oldest_tuple[0])
end
Не совсем. На Lua есть возможность установить курсор в индексе на нужный кортеж, и получить последующие кортежи.
Предыдущие кортежи получить пока нет возможности, но принципиально это то же самое, добавляется довольно просто.
В слайде опечатка. Изначально хотелось сказать про 170k в секунду. Сразу после форума больно тыкнули носом :) Ничего сложного нет, согласен. Всё дело в волшебных пузырьках количестве железа, которое есть в распоряжении. Правильная метрика — (запросы в секунду)/(стоимость железа * энергопотребление железа)
connection c1:
lock table t1 write;
connection c2:
select get_lock('test', 0)
connection c1:
select get_lock('test', 7200)
connection c2:
lock table t2 write;
Ну а теперь может быть такой дедлок:
connection c1:
select get_lock('test1', 0)
connection c2:
select get_lock('test2', 0)
connection c1:
select get_lock('test2', 7200)
connection c2:
select get_lock('test1', 7200)
Патч все такие дедлоки ловит, выдаёт ошибки. Точнее, ловит MDL, патч просто это всё использует.
А в остальном, думаю надо разбираться по ситуации, скорее всего это связано как-то с управлением задачами или очередями — когда нужно исключить возможность одновременной работы двух или более клиентов, выполнить какую-то нетривиальную синхронизацию.
— выкидывать на рынок решение с закрытым исходным кодом
— нарушать GPL
— основывать архитектуру in-memory database на основе кода MySQL, Которому 15 лет и который *не айс*, как по качеству кода так и по архитектурным решениям.
Я, конечно, человек ангажированный, но всё это похоже на какую-то разводку (с)
Сравнение в этом ключе со всеми остальными базами мне кажется мало уместным, т.к. у конкурентов будет профиль по потреблению памяти совсем другой (индексы по каждому атрибуту таки требуют памяти).
Интересно, что они при этом сразу сделали кластер. Их кластерное решение мне кажется любопытным, т.к. они обеспечивают атомарность за счёт записи изменений на несколько узлов кластера. Это правильно, быстрее чем диск, так поступает NDBCluster. Но и памяти это потребляет, по моим представлениям, соответственно.
Всё что происходит очень похоже на способ маркетинга стартапа, т.к сразу готов сайт, бенчмарки, списки рассылки и т.п., о преимуществах они говорят, а о недостатках и ограничениях предоставляют сообществу сделать вывод самостоятельно.
Возможно, я не прав в своих оценках, т.к. потратил на продукт только 30 минут и ушёл пилить Tarantool.
Open Source мир так не живёт, community строится не сразу, особенно в такой насыщенной поляне как NoSQL.
Также неплохо было бы выложить SHOW CREATE TABLE на t, p и u.
Есть также простейшая статистика, которая собирается ANALYZE TABLE.
В MariaDB велась также работа над более продвинутой статистики.
2) Балансировка каждый раз частичная, проблем с доступностью не возникает.
3) Этого как раз нет, я пытался чётко отписаться, что данные между узлами тарантула мы автоматически балансировать не умеем.
POSIX threads требую использования механизмов синхронизации при доступе к общим данным.
Т.к. каждый запрос мал, то издержки на эти механизмы будут сравнимы с издержками на всё выполнение запроса. Т.е. для этой задачи POSIX threads получаются слишком тяжеловесны.
Балансировка данных в деревьях у нас есть.
С++ опасен так же тем, что на нём очень легко писать плохие программы — слишком много способов использовать механизмы языка неправильно.
Кроме того, за счёт богатства языка, при работе в команде очень много времени уходит на утряску единого стиля программирования, выработку общих соглашений об использовании или неиспользовании средств языка.
Мой опыт программирования на С++ 10 лет.
oldest_tuple = box.space[0].index[1]:min()
while oldest_tuple[1] < 123456 do
box.space[0]:delete(oldest_tuple[0])
end
Предыдущие кортежи получить пока нет возможности, но принципиально это то же самое, добавляется довольно просто.
волшебных пузырькахколичестве железа, которое есть в распоряжении. Правильная метрика — (запросы в секунду)/(стоимость железа * энергопотребление железа)