LINUX.ORG.RU

Посоветуйте кластерную БД с SQL API

 ,


1

4

Посоветуйте реляцинную БД (точнее, любую бд с полной поддержкой стандарта SQL в её API, неважно на чем написан движок), которая могла бы в кластеризацию, при этом была бы бесплатной и под открытой/свободной лицензией. Цель - кластеризация запросов, включая кластерные джойны, на количестве серверов начиная от сотен.

Фокус на OLTP.

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

Пожертвовать можно доступностью
Прям совсем настоящий SQL не нужен, но база в виде джойнов, экзистов, подселектов, итп быть должна

Есть чего?
Пасиба :)

★★★★☆

Последнее исправление: stevejobs (всего исправлений: 1)

Посмотри postgresql xl и в сторону Hive, Spark и прочих зверей из того же разряда.

TOXA ★★
()

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

Не взлетит тут реляционная СУБД. При междатацентровом взаимодействии strong consistency не позволит тебе в приемлимые сроки писать/читать.

xpahos ★★★★★
()

Возможно, это не то, что тебе нужно, но... опыт avito.ru не изучал? У них как раз кластеры на базе PostgreSQL. Вот про количество серверов не в курсе.

hobbit ★★★★★
()

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

dave ★★★★★
()
Ответ на: комментарий от dave

ну, есть всякие хитрые хаки как поиметь систему, например то что в Кассандре - может и на мою задачу найдутся хаки :)

stevejobs ★★★★☆
() автор топика

Ты сам как это видишь? Какие профили нагрузки? Какого вида запросы, какая примерно частота, чего больше, чего меньше?

migesok
()
Ответ на: комментарий от migesok

Поехавший чёль?

я бы еще выпил!

В бизнес-логике есть понятие «сессия». Физически сессия выглядит как транзакция, внутри которой выполняется 100500 подтранзакций.

Всё что находится внутри сессии должно чётенько выполняться. А вот стартовать сессии - уже по возможности. Нету ресурсов на новую сессию - в очередь сукины дети.

Иллюстрация: представь что ты - облачный провайдер. Есть набор инструкций для установки нового сервера (выделить ресурсы в облаке, установить ОС, прикладные программы, БД Оракл). Если создание нового сервера уже запущено, результат хочется получить как можно скорее, и поэтому прерывать эту процедуру нельзя. Тем более что бабки уже уплочены. А вот новых клиентов и их заявки на новые сервера можно динамить и откладывать сколько угодно долго.

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

Ну почему ты меня не слушаешь, бестолочь ты такая? Бери OrientDB!

anonymous
()
Ответ на: комментарий от migesok

приложение, расчитанное на сильно нормализованную SQL базу, нужно перетащить на in-memory NoSQL хранилище, не изменяя кода этого приложения (в том числе, по возможности не трогая запросов, или трогая с помощью автоматических скриптов-трансформеров)

спрашиваешь, зачем NoSQL на задачу, которая специально заточена для SQL? Потому что так надо. Это - смысл и суть поставленной задачи. Деталей развернуть не могу, ибо НДА.

мы написали трансформер из SQL в NoSQL (и организовали таким образом слой эмуляции SQL API над Couchbase), но производительность просела в over 9000 раз

хочется что-то такое же, но только написанное не школьниками типа меня, что даст потерю произвольности относительно Оракла не больше 3 раз (не 10, и уж точно не over 9000)

профили нагрузки, соответственно - best practices работы с классической реляционной БД. Больше всего find by id + update всё связанное, намного меньше insert (обычно в начале сессии), delete по ходу жизни почти нет (вместо этого всё помечается как «удалённое» с помощью update, а реальное удаление производится эпическим delete'ом в конце сессии)

stevejobs ★★★★☆
() автор топика
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от anonymous

Какой АТ-Консалтинг? АТ-Консалтинг Восток. Новосибирск, бизнес-центр Мост. Ну и ртлабс. ОриентДБ еще где-то используют? Ты сам пробовал?

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от pawnhearts

Мда, ты прав. Раньше уже закончилось. А теперь нам нужно победить CAP теорему, срочно!

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

Я че пасу, что у вас там за шараги в этом вашем Новосибирске? Отвечая на твой вопрос - да, пробовал.

anonymous
()
Ответ на: комментарий от anonymous

Эта шарага написала Госуслуги, которыми ты, как житель России, теперь обязан пользоваться :)))) Отвечая на твой вопрос - нет, еще не пробовал, при мне был Оракл, попробую.

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

А где джойны будут-то? В этих самых частых запросах «find by id»? И, если ты готов жертвовать доступностью, то как часто и насколько оно может быть недоступно?

migesok
()
Ответ на: комментарий от stevejobs

Эта шарага написала Госуслуги

Одно другому не мешает))))0)))

migesok
()
Ответ на: комментарий от stevejobs

Прошу извинить. Все комментарии не читал)

dave ★★★★★
()

Распределенность и ACID слабо совместимы. Если устраивает BASE, то смотри в сторону MariaDB Galera, neo4j, RethinkDB.

unlog1c ★★★
()

И кстати - какой траспорт между нодами? Езернет? Если он то начните в его выпиливания и выбрасывания. На нем вообще все будет тормозить

cvv ★★★★★
()
Ответ на: комментарий от stevejobs

Вам стоит посмотреть в сторону InfiniBand и usNIC. Я думаю что апачевский зверинец должен уметь эти интерфейсы.

МИнимальное время транзакции поверх Езернета порядка 100 микросекунд. Упомянутое мною умеет порядка одной микросекунды. А в вашем случае этот параметр критичен.

cvv ★★★★★
()
Последнее исправление: cvv (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.