Какая структура данных в Python позволяет моделировать NoSQL базы данных

Что проверяют

Понимаете ли вы, что за разными видами NoSQL стоит одна идея: доступ по ключу к данным без жёсткой схемы. В Python её лучше всего выражает dict. Следом обычно спрашивают, почему словарь быстрый и чего ему не хватает, чтобы стать настоящей базой.

Как отвечать

Основной ответ: словарь, а для вложенных документов словари и списки в связке, то есть та же модель, что у JSON. Дальше покажите, как она ложится на типы NoSQL:

• ключ-значение: плоский dict с ключами вида "user:1001" и любыми значениями. Это модель Redis в миниатюре;
• документная: словарь с вложенными словарями и списками. У разных записей может быть разный набор полей, как у документов в MongoDB;
• широкие колонки: словарь словарей data[row_key][column], где у каждой строки свой набор колонок. Так устроена модель Cassandra;
• графовая: список смежности dict[str, set[str]], множество даёт быструю проверку связи.

Почему именно словарь: это хэш-таблица, поиск, вставка и удаление по ключу в среднем за O(1). С Python 3.7 порядок вставки гарантирован языком. Ключ должен быть хэшируемым: строка, число или кортеж подойдут, список нет.

Сильный ответ называет, чего не хватает до базы: персистентности (помогут json, shelve или sqlite3), вторичных индексов (их придётся держать отдельными словарями и обновлять вручную), конкурентного доступа и объёмов больше оперативной памяти. Структуру документов в коде контролируют через TypedDict или модели pydantic.

Где спотыкаются

Называют pandas.DataFrame моделью Cassandra. Cassandra хранит широкие строки, сгруппированные по ключу партиции, а DataFrame это аналитическая таблица с одинаковыми колонками у всех строк.

Хранят записи в списке и ищут по нему перебором. Это O(n) на каждый запрос, ровно то, от чего уходит модель «ключ-значение».

Забывают про изменяемость: один и тот же вложенный словарь, положенный в два документа, меняется в обоих сразу. Для независимых копий нужен copy.deepcopy.