Мне нужно хранить данные транзакций для определенных учетных записей в QLDB. Можно ли как-то сделать разделение таким образом, чтобы QLDB хранила данные для одной учетной записи на одном сервере, чтобы мои фрагменты/запросы были быстрее?
Как сделать разделение QLDB эффективным?
comment
Привет Шитал. Что вы имеете в виду под разделением? QLDB в конце 2019 года не поддерживает секционирование.
- person Marc schedule 06.12.2019
comment
Эй, @Marc, я имею в виду, когда QLDB хранит данные в леджере, есть ли какой-либо механизм, с помощью которого я могу сделать мои запросы на выборку эффективными? Например, если у меня есть данные транзакций для нескольких учетных записей, могу ли я контролировать данные одной учетной записи, находящиеся на одном сервере?
- person Shital schedule 07.12.2019
comment
Будет, потому что разделов пока нет.
- person Marc schedule 09.12.2019
Ответы (2)
QLDB не имеет сервера. AWS намеренно абстрагирует серверы, и даже если вы сегодня знаете детали реализации, она может измениться в любое время без предупреждения.
Когда QLDB в конечном итоге будет поддерживать несколько разделов/осколков/цепочек, даже тогда вам не следует пытаться думать об этом с точки зрения серверов, потому что нет гарантии, что один «ключ» раздела будет существовать в ровно одном разделе. /сервер.
Чтобы пояснить, что я имею в виду, я сравню с DynamoDB. (Несмотря на то, что я знаю, что у них разный дизайн, я думаю, что все же полезно отметить.) При использовании DynamoDB ваши данные секционируются на основе хеш-ключа, но нет гарантии, что все данные для одного значение hashkey существует в одном разделе. QLDB может сделать что-то подобное, а может и нет, но не следует делать никаких предположений о лежащей в основе реализации при проектировании таблицы.
При этом вы можете повысить производительность запросов при получении данных для одной учетной записи, если вы создайте индекс для вашего поля accountId.
person
Matthew Pope
schedule
07.12.2019
Я думаю, что это вводит в заблуждение, но, возможно, я просто неправильно прочитал это. QLDB не имеет сервера, когда дело доходит до обработки транзакций. Ваше фактическое состояние (журнал и индексированное хранилище) никогда не деинициализируется. Он всегда существует в нескольких копиях на физических хостах. И все ваши данные в вашей бухгалтерской книге, независимо от того, какая таблица / индекс, находятся на одних и тех же хостах, потому что QLDB в конце 2019 года не поддерживает секционирование. Надеюсь, это проясняется.
- person Marc; 09.12.2019
Я знаю, что бессерверные продукты по-прежнему работают на серверах, но суть бессерверных предложений заключается в том, чтобы абстрагироваться от проблем, связанных с работой серверов. Прямо сейчас все данные могут находиться на одном и том же хосте, но нет гарантии, что они всегда будут верны, поэтому людям не следует пытаться разрабатывать свои таблицы на основе этого предположения. Я постараюсь сделать свой ответ немного более ясным, но не стесняйтесь редактировать его, добавляя исправления и/или пояснения.
- person Matthew Pope; 09.12.2019
Кажется, я понял вашу мысль, спасибо за разъяснения. Архитектура QLDB жестко разделяет операции чтения и записи. В традиционной БД очень желательно совместное размещение данных для чтения. В QLDB почти всегда будет лучше иметь таблицы и индексы на разных узлах, потому что, проще говоря, доступно больше операций ввода-вывода. Я не предвижу снижения производительности, если различные разделы чтения применялись прозрачно. Записи идут в Журнал, который разделен по-другому (по нитям).
- person Marc; 10.12.2019
В выпуске QLDB 2019 года нет разделов. Все ваши данные записываются в одну «ветвь» (раздел) журнала. В индексированном хранилище есть несколько копий ваших данных, но у каждого из этих узлов есть все данные (для всех ваших таблиц и индексов).
person
Marc
schedule
10.12.2019
