Комментарии 41
1,5^108Странная запись.
Если бы это была не стенограмма, а более краткий пост для хабрахабра — было бы значительно лучше, хоть материал и интересен
А что сложного в 17к запросах в секунду? Речь не про SQL, конечно.
В слайде опечатка. Изначально хотелось сказать про 170k в секунду. Сразу после форума больно тыкнули носом :) Ничего сложного нет, согласен. Всё дело в волшебных пузырьках количестве железа, которое есть в распоряжении. Правильная метрика — (запросы в секунду)/(стоимость железа * энергопотребление железа)
Спасибо за подробный пост.
Буду подробно изучать, т.к. инструмент очень нравится и планирую его активно использовать.
Сразу хотелось бы задать вопрос: он умеет делать выборки типа «значение больше/меньше какого-то», по вхождению строки?
Буду подробно изучать, т.к. инструмент очень нравится и планирую его активно использовать.
Сразу хотелось бы задать вопрос: он умеет делать выборки типа «значение больше/меньше какого-то», по вхождению строки?
Запрос «больше-меньше заданного» можно сделать на хранимых процедурах.
Т.е. на LUA путем последовательного перебора строк и сравнения значений?
Не совсем. На Lua есть возможность установить курсор в индексе на нужный кортеж, и получить последующие кортежи.
Предыдущие кортежи получить пока нет возможности, но принципиально это то же самое, добавляется довольно просто.
Предыдущие кортежи получить пока нет возможности, но принципиально это то же самое, добавляется довольно просто.
Нет-нет, я не о том.
Ну, живой пример, на SQL:
DELETE FROM sessions WHERE last_activity < 123456 (где 123456 — определенный epoch)
Ну, живой пример, на SQL:
DELETE FROM sessions WHERE last_activity < 123456 (где 123456 — определенный epoch)
На Луа это будет выглядеть примерно так:
oldest_tuple = box.space[0].index[1]:min()
while oldest_tuple[1] < 123456 do
box.space[0]:delete(oldest_tuple[0])
end
oldest_tuple = box.space[0].index[1]:min()
while oldest_tuple[1] < 123456 do
box.space[0]:delete(oldest_tuple[0])
end
т.е. таки перебором…
и за сколько (ну так, навскидку) переберется миллион записей (на машинке, как у вас в презе)?
и за сколько (ну так, навскидку) переберется миллион записей (на машинке, как у вас в презе)?
Я не вижу здесь перебора. Открыли индекс. Читаем в порядке от меньшего к большему. Пока есть кортежи с ключём меньше заданного, мы их удалям. Так же как делает любая СУБД. Перебор был бы если бы мы бежали по всем кортежам, сравнивали бы в них поле last_activity с заданным, и удаляли. Мы же идём по индексу и останавливаемся как только нашли первый неподходящий.
Как и многие NOSQL-щики, Костя повторяет чужие очепятки, говоря, что
«мир NoSQL отбросил знаменитую модель Эдгара Кодда и предложил такие парадигмы, как, например, Column Storage — хранение, ориентированное на столбцы, Key-Value Storage, JSON и XML форматы». Каким боком все это относится к NoSQL? Вертикальное хранилище вообще описывалось еще в 70-80 годах.
«мир NoSQL отбросил знаменитую модель Эдгара Кодда и предложил такие парадигмы, как, например, Column Storage — хранение, ориентированное на столбцы, Key-Value Storage, JSON и XML форматы». Каким боком все это относится к NoSQL? Вертикальное хранилище вообще описывалось еще в 70-80 годах.
Zen, я не утверждаю что NoSQLщики изобрели вертикальное хранилище. Если посмотрим на ныне почивший Kickfire (скорее всего и Vertica тоже, но на неё я не смотрел) имели column storage, но доступ к данным осуществлялся через реляционную модель и язык SQL. Идея в том, что в NoSQL часто берут column storage и открывают на уровне доступа к данным непосредственно уровень хранения данных.
Хотелось бы больше сравнений с другими NoSQL решениями, например pros and cons в сравнении с MongoDB. Первое, что я заметил это SQL вместо JS (скорее всего в докладе ещё что-то упоминалось, но большая статья в конце рабочего дня читалась вскользь). Что ещё?
персистентность — это актуальность?
Если бы мог, проголосовал бы 100 раз. Отличный пост.
Было бы в разделе про мир субд добавил бы легкое сравнение с другими вариантами.
Почему решили писать свое, а не адаптировать готовое решение и т.д.
Может это было в докладе, не смотрел.
Было бы в разделе про мир субд добавил бы легкое сравнение с другими вариантами.
Почему решили писать свое, а не адаптировать готовое решение и т.д.
Может это было в докладе, не смотрел.
Статья супер, очень интересно!
А видео, извинете, еще то гуано: В глючном плеере, на тормозном хостинге, с моно звуком записаным в левую дорогу, с нереальным шумом… После 5 минут просмотра аж голова болит. Хорошо хоть добрый человек стенограму сделал! Низкий тебе поклон.
А видео, извинете, еще то гуано: В глючном плеере, на тормозном хостинге, с моно звуком записаным в левую дорогу, с нереальным шумом… После 5 минут просмотра аж голова болит. Хорошо хоть добрый человек стенограму сделал! Низкий тебе поклон.
Отвечу на вопрос девушки по поводу MongoDB…
Включите журналирование коммандой "--journal" производительность не сильно пострадает, зато при падении сервера база подцепляется сразу. Вот пример с тестовой машины:
mongod.exe --logpath C:\data\logs --logappend --dbpath C:\data\db --directoryperdb --journal
У нас есть проблема хранения сессий. Сейчас мы используем для этого MongoDB. В Mongo есть проблема, мы не можем восстановить данные на момент падения из журналов. Мы используем предыдущий бэкап, который у нас есть. Поэтому есть погрешности, потери и т.п.
Включите журналирование коммандой "--journal" производительность не сильно пострадает, зато при падении сервера база подцепляется сразу. Вот пример с тестовой машины:
mongod.exe --logpath C:\data\logs --logappend --dbpath C:\data\db --directoryperdb --journal
Интересно, почему та часть, что «core» его написана на Objective C. Что довольно необычно.
Один из стандартных языков в gcc, не на c++ же писать :)
Я думаю С++ для таких вещей более популярен (бусты всякие есть и либ куча разных) и понятен большинству. Возможно Objective C и хорошо подходит для таких задач, но это все равно мне кажется необычным.
Моя позиция: С++ очен плохо совместим с C, т.к. требует RAII. В Objective C есть клауза @finally, что позволяет совмещать наличие исключений и обычный код на С, в котором нет авто-деструкторов.
С++ опасен так же тем, что на нём очень легко писать плохие программы — слишком много способов использовать механизмы языка неправильно.
Кроме того, за счёт богатства языка, при работе в команде очень много времени уходит на утряску единого стиля программирования, выработку общих соглашений об использовании или неиспользовании средств языка.
Мой опыт программирования на С++ 10 лет.
С++ опасен так же тем, что на нём очень легко писать плохие программы — слишком много способов использовать механизмы языка неправильно.
Кроме того, за счёт богатства языка, при работе в команде очень много времени уходит на утряску единого стиля программирования, выработку общих соглашений об использовании или неиспользовании средств языка.
Мой опыт программирования на С++ 10 лет.
А что с балансировкой/ребалансировкой?
(я так понимаю, речь шла о балансировке данных в кластере)
Балансировка данных в деревьях у нас есть.
Балансировка данных в деревьях у нас есть.
1) Она происходит автоматически или вручную надо запускать процесс?
2) Доступен ли при балансировке кластер?
3) Видят ли кластеры друг друга, чтобы балансировать между инстансами(физическими серверами) в кластере?
и еще один вопрос по другой теме, если можно.
Почему выбор остановился в пользу корутинных таскеров вместо трединга?
Как бы, единственным приемуществом я вижу ликвидацию головомороки с thread-safe writing. Может я упускаю еще какую-то выгоду…
Заранее спасибо
2) Доступен ли при балансировке кластер?
3) Видят ли кластеры друг друга, чтобы балансировать между инстансами(физическими серверами) в кластере?
и еще один вопрос по другой теме, если можно.
Почему выбор остановился в пользу корутинных таскеров вместо трединга?
Как бы, единственным приемуществом я вижу ликвидацию головомороки с thread-safe writing. Может я упускаю еще какую-то выгоду…
Заранее спасибо
1) Балансировка данных в бинарных деревьях, то есть индексах по данным, автоматическая.
2) Балансировка каждый раз частичная, проблем с доступностью не возникает.
3) Этого как раз нет, я пытался чётко отписаться, что данные между узлами тарантула мы автоматически балансировать не умеем.
POSIX threads требую использования механизмов синхронизации при доступе к общим данным.
Т.к. каждый запрос мал, то издержки на эти механизмы будут сравнимы с издержками на всё выполнение запроса. Т.е. для этой задачи POSIX threads получаются слишком тяжеловесны.
2) Балансировка каждый раз частичная, проблем с доступностью не возникает.
3) Этого как раз нет, я пытался чётко отписаться, что данные между узлами тарантула мы автоматически балансировать не умеем.
POSIX threads требую использования механизмов синхронизации при доступе к общим данным.
Т.к. каждый запрос мал, то издержки на эти механизмы будут сравнимы с издержками на всё выполнение запроса. Т.е. для этой задачи POSIX threads получаются слишком тяжеловесны.
Спасибо, так и предполагал.
Как бы получается, что реальное использование Тарантула больше подходит в качестве поддержки RDBMS и работе напрямую с клиентом. Строить на нем большой кластер данных в облаке(!!!) будет сложно в силу проблем балансировки и распределения данных между серверами внутри аппликейшена. Но если есть свои сервера, то проблема отпадает.
Как бы получается, что реальное использование Тарантула больше подходит в качестве поддержки RDBMS и работе напрямую с клиентом. Строить на нем большой кластер данных в облаке(!!!) будет сложно в силу проблем балансировки и распределения данных между серверами внутри аппликейшена. Но если есть свои сервера, то проблема отпадает.
Пока ничего.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Tarantool: как обрабатывать 1,5 млрд запросов в сутки?