Сообщение Re[15]: Что вы думаете о графовых базах данных? от 26.03.2023 21:54
Изменено 26.03.2023 21:55 VladiCh
Re[15]: Что вы думаете о графовых базах данных?
Здравствуйте, SkyDance, Вы писали:
G>>Мы сейчас о масштабировании?
SD>С самого начала nosql был "о масштабировании". Потому как другое "достоинство" (отсутствие схемы) на самом деле является недостатком.
G>>Для масштабирования вам нужен шаридинг — запросы по одному диапазону ключей идут в одну ноду, по другому диапазону — в другую.
SD>А теперь расскажите, как можно эффективно реализовать secondary indexes. Без которых РСУБД вырождаются в те самые nosql, key-value store. Стандартные подходы (например, упорядочивание записи — так что сначала пишем индекс, потом сам ключ) имеют определенные проблемы с эффективностью и атомарностью (после чтения индекса надо проверить, что ключи в самом деле существуют).
SD>
G>>А как такую же задачу решает любой nosql? С тем же referential integrity.
SD>Никак — nosql не имеет referential integrity
Для каждого конкретного отношения (relation) пишется своя бизнес-логика, обычно инкапсулировання где-то в отдельном сервисе. По факту каждый сервис из себя представляет в чем-то уникальную базу данных, высокая производительность которой основана на каких-то дополнительных знаниях о свойствах лежащих в БД объектов. Костыли, конечно, — ну так nosql для того и нужен. Можно это сравнить с применением FFI где-нибудь в Питоне: сам по себе он слишком тормозной, поэтому определенные задачи приходится решать на С.
G>>Если расскажете, то я вам расскажу как сделать это на РСУБД.
SD>И как же? Чем это будет лучше в сравнении с key-value store? И в чем вообще будут отличия? РСУБД для того и нужны, чтоб referential integrity (и ACID вообще) реализовывать.
РСУБД и высокопроизводительные сервисы это вообще малосовместимые понятия. Не на уровне ядра РСУБД малосовместимые, а на уровне интерфейса (SQL).
SQL — это декларативный интерфейс, когда оптимизатор сам решает как именно выполнять конкретный запрос. К сожалению, ни одна существующая реализация оптимизатора не выполняет эту работу сколько-нибудь эффективно для больших данных
(стоимость поддержки актуальной статистики оптимизатора растет линейно с ростом размера данных и есть подозрение что это вообще невозможно для достаточно больших баз данных).
Изначально SQL был сделан максимально дружелюбным для пользователя, чтобы им могли пользоваться не-программисты. Ну и проблемы растут в основном из этого.
Если же отойти от этой проблемы, принципиально нет причин по которым РСУБД (на уровне движка) не могли бы масштабироваться не хуже чем NoSQL. Наделать кучу шардов дурное дело нехитрое.
Поддерживать согласованность данных в разных шардах все равно потребуется какими-то внешними способами (как в случае NoSQL так и РСУБД). Плюс в случае РСУБД у тебя есть дополнительный бонус транзакционности на уровне одного шарда.
G>>Мы сейчас о масштабировании?
SD>С самого начала nosql был "о масштабировании". Потому как другое "достоинство" (отсутствие схемы) на самом деле является недостатком.
G>>Для масштабирования вам нужен шаридинг — запросы по одному диапазону ключей идут в одну ноду, по другому диапазону — в другую.
SD>А теперь расскажите, как можно эффективно реализовать secondary indexes. Без которых РСУБД вырождаются в те самые nosql, key-value store. Стандартные подходы (например, упорядочивание записи — так что сначала пишем индекс, потом сам ключ) имеют определенные проблемы с эффективностью и атомарностью (после чтения индекса надо проверить, что ключи в самом деле существуют).
SD>
| Скрытый текст | |
| SD>Вопросом распределенных БД я некоторое время занимаюсь очень плотно, и в теме разбираюсь более чем. Не знаю, какой опыт у вас, могу лишь судить по заявлениям типа "вы не умеете их готовить". В этой области есть несколько фундаментальных проблем, у которых пока нет общепринятого решения. Я уже три раза упоминал Spanner (как одну из реализаций, основанной на применении высокоточного таймера), и Calvin, основанный на детерминированном исполнении очереди транзакций, порядок которых выбирается лидером RAFT). Это должно было навести вас на определенные мысли о том, что я таки знаю, о чем пишу. Если же вы с этими протоколами не знакомы, значит, вам просто не требовалось решать масштабные задачи, и для вас РСУБД действительно достаточны. | |
G>>А как такую же задачу решает любой nosql? С тем же referential integrity.
SD>Никак — nosql не имеет referential integrity
Для каждого конкретного отношения (relation) пишется своя бизнес-логика, обычно инкапсулировання где-то в отдельном сервисе. По факту каждый сервис из себя представляет в чем-то уникальную базу данных, высокая производительность которой основана на каких-то дополнительных знаниях о свойствах лежащих в БД объектов. Костыли, конечно, — ну так nosql для того и нужен. Можно это сравнить с применением FFI где-нибудь в Питоне: сам по себе он слишком тормозной, поэтому определенные задачи приходится решать на С.G>>Если расскажете, то я вам расскажу как сделать это на РСУБД.
SD>И как же? Чем это будет лучше в сравнении с key-value store? И в чем вообще будут отличия? РСУБД для того и нужны, чтоб referential integrity (и ACID вообще) реализовывать.
РСУБД и высокопроизводительные сервисы это вообще малосовместимые понятия. Не на уровне ядра РСУБД малосовместимые, а на уровне интерфейса (SQL).
SQL — это декларативный интерфейс, когда оптимизатор сам решает как именно выполнять конкретный запрос. К сожалению, ни одна существующая реализация оптимизатора не выполняет эту работу сколько-нибудь эффективно для больших данных
(стоимость поддержки актуальной статистики оптимизатора растет линейно с ростом размера данных и есть подозрение что это вообще невозможно для достаточно больших баз данных).
Изначально SQL был сделан максимально дружелюбным для пользователя, чтобы им могли пользоваться не-программисты. Ну и проблемы растут в основном из этого.
Если же отойти от этой проблемы, принципиально нет причин по которым РСУБД (на уровне движка) не могли бы масштабироваться не хуже чем NoSQL. Наделать кучу шардов дурное дело нехитрое.
Поддерживать согласованность данных в разных шардах все равно потребуется какими-то внешними способами (как в случае NoSQL так и РСУБД). Плюс в случае РСУБД у тебя есть дополнительный бонус транзакционности на уровне одного шарда.
Re[15]: Что вы думаете о графовых базах данных?
Здравствуйте, SkyDance, Вы писали:
G>>Мы сейчас о масштабировании?
SD>С самого начала nosql был "о масштабировании". Потому как другое "достоинство" (отсутствие схемы) на самом деле является недостатком.
G>>Для масштабирования вам нужен шаридинг — запросы по одному диапазону ключей идут в одну ноду, по другому диапазону — в другую.
SD>А теперь расскажите, как можно эффективно реализовать secondary indexes. Без которых РСУБД вырождаются в те самые nosql, key-value store. Стандартные подходы (например, упорядочивание записи — так что сначала пишем индекс, потом сам ключ) имеют определенные проблемы с эффективностью и атомарностью (после чтения индекса надо проверить, что ключи в самом деле существуют).
SD>
G>>А как такую же задачу решает любой nosql? С тем же referential integrity.
SD>Никак — nosql не имеет referential integrity Для каждого конкретного отношения (relation) пишется своя бизнес-логика, обычно инкапсулировання где-то в отдельном сервисе. По факту каждый сервис из себя представляет в чем-то уникальную базу данных, высокая производительность которой основана на каких-то дополнительных знаниях о свойствах лежащих в БД объектов. Костыли, конечно, — ну так nosql для того и нужен. Можно это сравнить с применением FFI где-нибудь в Питоне: сам по себе он слишком тормозной, поэтому определенные задачи приходится решать на С.
G>>Если расскажете, то я вам расскажу как сделать это на РСУБД.
SD>И как же? Чем это будет лучше в сравнении с key-value store? И в чем вообще будут отличия? РСУБД для того и нужны, чтоб referential integrity (и ACID вообще) реализовывать.
РСУБД и высокопроизводительные сервисы это вообще малосовместимые понятия. Не на уровне ядра РСУБД малосовместимые, а на уровне интерфейса (SQL).
SQL — это декларативный интерфейс, когда оптимизатор сам решает как именно выполнять конкретный запрос. К сожалению, ни одна существующая реализация оптимизатора не выполняет эту работу сколько-нибудь эффективно для больших данных
(стоимость поддержки актуальной статистики оптимизатора растет линейно с ростом размера данных и есть подозрение что это вообще невозможно для достаточно больших баз данных).
Изначально SQL был сделан максимально дружелюбным для пользователя, чтобы им могли пользоваться не-программисты. Ну и проблемы растут в основном из этого.
Если же отойти от этой проблемы, принципиально нет причин по которым РСУБД (на уровне движка) не могли бы масштабироваться не хуже чем NoSQL. Наделать кучу шардов дурное дело нехитрое.
Поддерживать согласованность данных в разных шардах все равно потребуется какими-то внешними способами (как в случае NoSQL так и РСУБД). Плюс в случае РСУБД у тебя есть дополнительный бонус транзакционности на уровне одного шарда.
G>>Мы сейчас о масштабировании?
SD>С самого начала nosql был "о масштабировании". Потому как другое "достоинство" (отсутствие схемы) на самом деле является недостатком.
G>>Для масштабирования вам нужен шаридинг — запросы по одному диапазону ключей идут в одну ноду, по другому диапазону — в другую.
SD>А теперь расскажите, как можно эффективно реализовать secondary indexes. Без которых РСУБД вырождаются в те самые nosql, key-value store. Стандартные подходы (например, упорядочивание записи — так что сначала пишем индекс, потом сам ключ) имеют определенные проблемы с эффективностью и атомарностью (после чтения индекса надо проверить, что ключи в самом деле существуют).
SD>
| Скрытый текст | |
| SD>Вопросом распределенных БД я некоторое время занимаюсь очень плотно, и в теме разбираюсь более чем. Не знаю, какой опыт у вас, могу лишь судить по заявлениям типа "вы не умеете их готовить". В этой области есть несколько фундаментальных проблем, у которых пока нет общепринятого решения. Я уже три раза упоминал Spanner (как одну из реализаций, основанной на применении высокоточного таймера), и Calvin, основанный на детерминированном исполнении очереди транзакций, порядок которых выбирается лидером RAFT). Это должно было навести вас на определенные мысли о том, что я таки знаю, о чем пишу. Если же вы с этими протоколами не знакомы, значит, вам просто не требовалось решать масштабные задачи, и для вас РСУБД действительно достаточны. | |
G>>А как такую же задачу решает любой nosql? С тем же referential integrity.
SD>Никак — nosql не имеет referential integrity
Для каждого конкретного отношения (relation) пишется своя бизнес-логика, обычно инкапсулировання где-то в отдельном сервисе. По факту каждый сервис из себя представляет в чем-то уникальную базу данных, высокая производительность которой основана на каких-то дополнительных знаниях о свойствах лежащих в БД объектов. Костыли, конечно, — ну так nosql для того и нужен. Можно это сравнить с применением FFI где-нибудь в Питоне: сам по себе он слишком тормозной, поэтому определенные задачи приходится решать на С.G>>Если расскажете, то я вам расскажу как сделать это на РСУБД.
SD>И как же? Чем это будет лучше в сравнении с key-value store? И в чем вообще будут отличия? РСУБД для того и нужны, чтоб referential integrity (и ACID вообще) реализовывать.
РСУБД и высокопроизводительные сервисы это вообще малосовместимые понятия. Не на уровне ядра РСУБД малосовместимые, а на уровне интерфейса (SQL).
SQL — это декларативный интерфейс, когда оптимизатор сам решает как именно выполнять конкретный запрос. К сожалению, ни одна существующая реализация оптимизатора не выполняет эту работу сколько-нибудь эффективно для больших данных
(стоимость поддержки актуальной статистики оптимизатора растет линейно с ростом размера данных и есть подозрение что это вообще невозможно для достаточно больших баз данных).
Изначально SQL был сделан максимально дружелюбным для пользователя, чтобы им могли пользоваться не-программисты. Ну и проблемы растут в основном из этого.
Если же отойти от этой проблемы, принципиально нет причин по которым РСУБД (на уровне движка) не могли бы масштабироваться не хуже чем NoSQL. Наделать кучу шардов дурное дело нехитрое.
Поддерживать согласованность данных в разных шардах все равно потребуется какими-то внешними способами (как в случае NoSQL так и РСУБД). Плюс в случае РСУБД у тебя есть дополнительный бонус транзакционности на уровне одного шарда.