Tarantool как единственная БД - это возможно?

[Roman Shishkin]

Всем доброго дня!

Пытаюсь найти ответ на вопрос можно ли использовать tarantool как единственную базу данных принципиально как идеологию и как хранилище данных в моем  конкретном случае.

1. Насколько tarantool надежен в плане persitence? Интересно услышать видение разработчиков.

Для себя я давно сделал вывод, что при малом объеме данных SQL баз в проектах проще все скопировать в память

и в ней уже гонять key/value массивы. При огромном количестве данных и пользователей снова в сервисе нужно ставить Memcache, Redis,

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

Так почему бы сразу не спроектировать систему так, что бы в ней осталось только in-memory хранилище?

Как то так: https://habrahabr.ru/post/178525/

Теперь к данным. Планируется собирать запросы и геометки пользователей, затем выполнять геолокационные вычисления и возвращать рекомендации. Планируем некий набор данных:

1. Таблица пользователей - тут все понятно.

2. Таблица хранения сессии (состояний). Состояний много и по сути это реализация конечного автомата для пошагового достижения некоторого конечного состояния типа бронирования поездки из пункта A в Пункт Б. У каждого существующего пользователя есть сессия, неплохо было бы сохранять и проейденные состояния для анализа и оптимизации.

3. Треки, точки сбора. Маршруты и области в пространстве и времени среди которых надо искать пересечение. В случае  нахождения стыковок сервис высылает оповещение пользователю. Треки имеют время жизни, создаются небольшой группой активных пользователей.

4. Геоданные. Вот тут самое интересное. Возникла безумная идея развернуть все геоданные в двумерный массивы типа country[x][y], в котором каждая точка содержит 4 или 8 байт информации (слои) о географических объектах.  Например, абонент посылает в систему координаты своей локацию [x][y], а мы по сути одним процессорным тактом из массива извлекаем байт страны, байт региона, два байта местности.

Получается  описание локации: Россия, Московская обл, Кресная Площадь. Дальше мы в обычных гео справочниках для этого района находим список достопримечательностей и выдаем нашим пользователям место встречи, скажем, "в Гуме у фонтана".

По моим прикидкам для площади земли 510 мл кв. км и 4 байта на точку, достаточно всего 2 Гбайта памяти. И это сегодня - копеешный выделенный виртуальный сервер.  Но нам не нужно, с одной стороны, покрывать весь земной шар, достаточно оставить конкретную страну. С другой стороны разрешение может быть не 1 км, а 500 или 100 метров, так что объем данных примерно понятен.

Поскольку я, в целом, дилетант, то хотел бы спросить совета у разработчиков системы можно ли реализовать искомую модель данных в tarantool?  Если можно, то подскажите какие типы данных использовать, посоветуйте примеры.

Я обсуждал концепцию с профессиональными программистами, они округляли глаза, начинали говорить про SQL,облачные сервисы, API, какие то сервисы, которые дают 100 запросов в день бесплатно. Я не понимаю зачем громоздить сущности друг на друга, если можно написать простую программу с быстрыми алгоритмами, которая все рассчитает из памяти.

К сожалению, пока, в отличие от Redis информации об Tarantool сильно меньше. Надеюсь что мой вопрос немного отвлечет разработчиков от решения рутинных задач. Заранее благодарю за ответы!

[Dmitry E. Oboukhov]

> Всем доброго дня!

> Пытаюсь найти ответ на вопрос можно ли использовать tarantool как единственную
> базу данных принципиально как идеологию и как хранилище данных в моем
> конкретном случае.

> 1. Насколько tarantool надежен в плане persitence? Интересно услышать видение
> разработчиков.

не менее надежен чем скажем постгрис.
Если Вы получили положительный ответ (код ответа по протоколу, либо
возврат управления в lua) о записи, значит данные уже на диске.

> По моим прикидкам для площади земли 510 мл кв. км и 4 байта на точку,
> достаточно всего 2 Гбайта памяти. И это сегодня - копеешный выделенный
> виртуальный сервер.  Но нам не нужно, с одной стороны, покрывать весь земной
> шар, достаточно оставить конкретную страну. С другой стороны разрешение может
> быть не 1 км, а 500 или 100 метров, так что объем данных примерно понятен.

> Поскольку я, в целом, дилетант, то хотел бы спросить совета у разработчиков
> системы можно ли реализовать искомую модель данных в tarantool?  Если можно, то
> подскажите какие типы данных использовать, посоветуйте примеры.

карты Mail.RU работали над тем чтобы в тарантул карту планеты
положить.
расчеты у вас примерно похожи на реальность, ну только на коэффициент
придется умножить и (возможно) настройками слабаллокатора в box.cfg
поиграть.

> Я обсуждал концепцию с профессиональными программистами, они округляли глаза,
> начинали говорить про SQL,облачные сервисы, API, какие то сервисы, которые дают
> 100 запросов в день бесплатно. Я не понимаю зачем громоздить сущности друг на
> друга, если можно написать простую программу с быстрыми алгоритмами, которая
> все рассчитает из памяти.

только вот считать на стороне lua тарантула треки не рекомендую.
в гео - там много математики (синусы/арктангенсы) а CPU все-таки один.
то есть если Вы геоданные кладете, то используете RTREE индекс, а
математика на клиенте.

либо придется масштабировать на множество инстансов тарантула,
либо можно взять постгрис: более мощной поддержки гео пока нет ни в
одной БД

--
_______________
< tarantool.org > Mail.RU
---------------
\ ^__^
\ (oo)\_______
(__)\ )\/\ Dmitry E. Oboukhov <un...@debian.org>
U ||----w | GPGKey: 1024D / F8E26537 2006-11-21
|| || 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537

[Dmitry Boytsov]

среда, 6 апреля 2016 г., 17:55:56 UTC+3 пользователь Roman Shishkin написал:

Теперь к данным. Планируется собирать запросы и геометки пользователей, затем выполнять геолокационные вычисления и возвращать рекомендации. Планируем некий набор данных:

1. Таблица пользователей - тут все понятно.

2. Таблица хранения сессии (состояний). Состояний много и по сути это реализация конечного автомата для пошагового достижения некоторого конечного состояния типа бронирования поездки из пункта A в Пункт Б. У каждого существующего пользователя есть сессия, неплохо было бы сохранять и проейденные состояния для анализа и оптимизации.

3. Треки, точки сбора. Маршруты и области в пространстве и времени среди которых надо искать пересечение. В случае  нахождения стыковок сервис высылает оповещение пользователю. Треки имеют время жизни, создаются небольшой группой активных пользователей.

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

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

Может быть разработчики Тарантула тут прояснят этот вопрос.

 

4. Геоданные. Вот тут самое интересное. Возникла безумная идея развернуть все геоданные в двумерный массивы типа country[x][y], в котором каждая точка содержит 4 или 8 байт информации (слои) о географических объектах.  Например, абонент посылает в систему координаты своей локацию [x][y], а мы по сути одним процессорным тактом из массива извлекаем байт страны, байт региона, два байта местности.

 

Получается  описание локации: Россия, Московская обл, Кресная Площадь. Дальше мы в обычных гео справочниках для этого района находим список достопримечательностей и выдаем нашим пользователям место встречи, скажем, "в Гуме у фонтана".

По моим прикидкам для площади земли 510 мл кв. км и 4 байта на точку, достаточно всего 2 Гбайта памяти. И это сегодня - копеешный выделенный виртуальный сервер.  Но нам не нужно, с одной стороны, покрывать весь земной шар, достаточно оставить конкретную страну. С другой стороны разрешение может быть не 1 км, а 500 или 100 метров, так что объем данных примерно понятен.

В Вашем случае, как мне видится, Вы можете эффективно использовать только 1 переменную-координату для описания местоположения объектов, и через нее же искать ближайшие объекты.

Посмотрите в сторону Quadtree/Geohash:

https://en.wikipedia.org/wiki/Geohash

http://ojalesa.mbnet.fi/quadtree/quadtree_intro.htm

[Konstantin Osipov]

* Dmitry Boytsov <boy...@gmail.com> [16/04/07 14:13]:

>
> В свое время у меня программисты столкнулись с проблемой — есть ограничение
> на кол-во составных индексов. Когда полей относительно много (десятки), и
> нужно делать запросы с разными комбинациями по разным полям, то индексов не
> хватает.
> Возможно что-то изменилось, или наши программисты не докрутили, но Вы
> уточните этот момент.
>
> Может быть разработчики Тарантула тут прояснят этот вопрос.

Я поднял лимит до 128 индексов на спейс в 1.6

tarantool> box.schema.INDEX_MAX
---
- 128
...


--
Konstantin Osipov, Moscow, Russia, +7 903 626 22 32
http://tarantool.org - www.twitter.com/kostja_osipov

[Roman Shishkin]

Дмитрий, спасибо за ответы! Может и другие участники найдут время что то написать.

Про RTREE я почитал, очень хорошая идея использовать их для хранения информации об географических объектах.

К сожалению, я пока не разобрался окончательно как хранить обычный, достаточно большой массив данных. Что будет если сделать tuple set содержащий два индекса  0.. 1024 хранящий number? А если сделать tuples c двумя индексами 0 ... 65535? Какие накладные расходы на память? Это эффективно в плане выборки и хранения или нет?

Пару слов про индексы: 
1. Если мы в прямоугольном массиве кодируем географическую фигуру, то  смело какие то индексы пропускаем. Получится экономия памяти на пустых местах.
2. Можно использовать запрос на извлечение элемента с определенным индексом как проверку на существование
3. Если индекс существует, то можно вернуть тип numbers или string. И там и там значение в памяти будет занимать переменную длину и значит опять возможна экономия памяти, если много "коротких" точек.

Я правильно понимаю это вышеперечисленное?

среда, 6 апреля 2016 г., 18:08:25 UTC+2 пользователь Dmitry E. Oboukhov написал:

> Всем доброго дня!

[Konstantin Osipov]

* Roman Shishkin <r.shi...@gmail.com> [16/04/07 20:01]:

Роман, я перечитал оригинальное письмо, и это, и я просто не
понимаю многих Ваших вопросов. Надо как-то иначе сформулировать.

Какую задачу вы пытаетесь решить?

[Roman Shishkin]

Константин, я изучаю возможность использования tarantool.

Вопросы такие.

1. Можно ли использовать tarantool как основную БД. Ответ: можно.

2. Как хранить пространственные геообъекты. Ответ: например с помощью индексов RTREE

3. Как хранить большие двумерные массивы. Например 1024 x 1024 x int32 ? Можно ли массив 3 хранить внутри объекта 2?

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

7 апреля 2016 г., 19:35 пользователь Konstantin Osipov <kostja...@gmail.com> написал:

--
Вы получили это сообщение, так как подписаны на группу "tarantool-ru".
Чтобы отменить подписку на эту тему, перейдите по ссылке https://groups.google.com/d/topic/tarantool-ru/kiXLqnwvCuo/unsubscribe.
Чтобы отменить подписку на эту группу и все ее темы, отправьте письмо на электронный адрес tarantool-ru...@googlegroups.com.

Настройки подписки и доставки писем: https://groups.google.com/d/optout.

--

Best regards,
Roman Shishkin

[Konstantin Osipov]

* Roman Shishkin <r.shi...@gmail.com> [16/04/07 21:23]:

> 3. Как хранить большие двумерные массивы. Например 1024 x 1024 x int32 ?
> Можно ли массив 3 хранить внутри объекта 2?

Они плотные или разреженные?

[Roman Shishkin]

Изначально рассматривал плотные, но если получаются разреженные, то выйдет экономия памяти около 30%.

7 апреля 2016 г., 20:25 пользователь Konstantin Osipov <kostja...@gmail.com> написал:

--
Вы получили это сообщение, так как подписаны на группу "tarantool-ru".
Чтобы отменить подписку на эту тему, перейдите по ссылке https://groups.google.com/d/topic/tarantool-ru/kiXLqnwvCuo/unsubscribe.
Чтобы отменить подписку на эту группу и все ее темы, отправьте письмо на электронный адрес tarantool-ru...@googlegroups.com.
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

[Konstantin Osipov]

* Roman Shishkin <r.shi...@gmail.com> [16/04/07 21:39]:

>
> 7 апреля 2016 г., 20:25 пользователь Konstantin Osipov <
> kostja...@gmail.com> написал:
>
> > * Roman Shishkin <r.shi...@gmail.com> [16/04/07 21:23]:
> >
> > > 3. Как хранить большие двумерные массивы. Например 1024 x 1024 x int32 ?
> > > Можно ли массив 3 хранить внутри объекта 2?
> >
> > Они плотные или разреженные?

> Изначально рассматривал плотные, но если получаются разреженные, то выйдет
> экономия памяти около 30%.

Что с ними планируется делать? Если только хранить, то это просто
блоб для Tarantool, всё равно как оно представлено, важен только
общий объём таких данных. Если внутри базы как-то обрабатывать, то
как?

[Roman Shishkin]

Необходимо сделать выборку по координатам x,y и получить 32 битное слово.  Это прямая прямая адресация к ячейке памяти x+y*HeightOfArray.

Не нужно категорически передавать в приложение весь объект. Это всю идею разрушает. 

Blob это хорошее, только я не увидел ни одного упоминания о нем в документации. Может быть есть какой то пример?

7 апреля 2016 г., 21:57 пользователь Konstantin Osipov <kostja...@gmail.com> написал:

--
Вы получили это сообщение, так как подписаны на группу "tarantool-ru".
Чтобы отменить подписку на эту тему, перейдите по ссылке https://groups.google.com/d/topic/tarantool-ru/kiXLqnwvCuo/unsubscribe.
Чтобы отменить подписку на эту группу и все ее темы, отправьте письмо на электронный адрес tarantool-ru...@googlegroups.com.
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

[Konstantin Osipov]

* Roman Shishkin <r.shi...@gmail.com> [16/04/08 00:07]:

> Необходимо сделать выборку по координатам x,y и получить 32 битное слово.
> Это прямая прямая адресация к ячейке памяти x+y*HeightOfArray.
> Не нужно категорически передавать в приложение весь объект. Это всю идею
> разрушает.

Сколько всего таких матриц собираетесь хранить?

Какой объём обновлений в секунду? Как часто меняете матрицу
целиком, а как часто отдельные поля?

Какой объём чтений в секунду?

[Roman Shishkin]

Одна матрица - это один географический регион. Можно сделать больше регионов, тогда будет меньше их размер.  В чистых данных это будет несколько гигабайт и величина постоянная пока не добавляется очередной регион.

Обновление матрицы, вероятно, должно выполнятся целиком и будет крайне редким событием.

А вот чтение должно быть быстрым. На лавры higload я не претендую, поэтому вопрос меня немного ставит в тупик. Насколько медленнее это будет по сравнению с  быстрым чтением из нормального key/value хранилища?

7 апреля 2016 г., 23:32 пользователь Konstantin Osipov <kostja...@gmail.com> написал:

[Konstantin Osipov]

* Roman Shishkin <r.shi...@gmail.com> [16/04/08 09:59]:

> Одна матрица - это один географический регион. Можно сделать больше
> регионов, тогда будет меньше их размер. В чистых данных это будет
> несколько гигабайт и величина постоянная пока не добавляется очередной
> регион.
>
> Обновление матрицы, вероятно, должно выполнятся целиком и будет крайне
> редким событием.
>
> А вот чтение должно быть быстрым. На лавры higload я не претендую, поэтому
> вопрос меня немного ставит в тупик. Насколько медленнее это будет по
> сравнению с быстрым чтением из нормального key/value хранилища?

Чтение идёт по 2ум координатам всегда или только по одной может
быть?

[Roman Shishkin]

Всегда по двум.

8 апреля 2016 г., 10:19 пользователь Konstantin Osipov <kostja...@gmail.com> написал:

--

Вы получили это сообщение, так как подписаны на группу "tarantool-ru".
Чтобы отменить подписку на эту тему, перейдите по ссылке https://groups.google.com/d/topic/tarantool-ru/kiXLqnwvCuo/unsubscribe.
Чтобы отменить подписку на эту группу и все ее темы, отправьте письмо на электронный адрес tarantool-ru...@googlegroups.com.
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

[Konstantin Osipov]

* Roman Shishkin <r.shi...@gmail.com> [16/04/08 14:35]:
> Всегда по двум.

В таком случае, имхо вполне можно хранить id, x, y в качестве
полей. Да, будет определённый расход памяти на хранение координат,
но запросы будут работать с предсказуемой производительностью.

[Alexandre Kalendarev]

Я работал в проекте, где редис был как единственная основная БД, расшаржен между 8 машинами.

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

Не вижу причин, почему бы его не использовать как основную БД.

у меня был проект, я там Тарантул использовал как оперативный кеш, все данные играющих пользователей находились в Тарантуле и шел обмен только с тарантулом. Кеш скидывался в БД только в критически важных случаях:  оплаты пользоватем или достижения нового уровня. А так же после выхода пользователя из игры.

 так что, с точки надежности - все хорошо, есть репликация и можно настроить failover

единственное что нужно помнить, что Тарантул - мемори-онли хранилище и нужно следить за памятью. Но сейчас у нас серввера мощные (до 128 Гиг), можно настроить шардинг если что...

 

[Eugene Kolobov]

Насколько я посмотрел в Tarantool все надежно и персистится на диск, но все равно многие сохраняют некоторые данные игры (типа транзакций итп) еще в одну базу как бекап. Зачем нужно это делать, если тарантул надежен и поднимается из WAL и снапов? 

Я просто сейчас тоже проектирую базу для многопользовательской игры и один из главных сервисов работы с пользователями - все профили, уровни пользователей их покупки итп хочу хранить прямо в тарантуле не поднимая дополнительно постгри для этого. Можно конечно делать бекап старых пользователей, которые давно не играют в постгри и после этого удалять их из тарантула, чтобы в случае возвращения можно было бы их восстановить, но вот для каких-то других целей не вижу смысла, тут я думаю тарантул данные не потеряет. Конечно все зависит от объема данных на пользователя, у нас там все оптимально и данных совсем не много получается в 2 ГБ оперативы можно хранить очень большое число пользователей.

Ну плюс есть реплики и шарды, failover поднимается, так что я думаю тарантул не плох как единственная база. У меня ощущение, что половина сервисов Mail.ru так работает теперь, судя по докладам на HighLoad.