Понимание MongoDB BSON Ограничение размера документа

Question

Понимание MongoDB BSON Ограничение размера документа

117

От MongoDB Полное руководство:

Документы размером более 4 МБ (при преобразовании в BSON) не могут быть сохранен в базе данных. Это несколько произвольный предел (и может быть в будущем); это главным образом предотвращение плохой схемы и стабильная производительность.

Я не понимаю этого предела, означает ли это, что документ, содержащий запись в блоге с большим количеством комментариев, которая просто так превышает 4 МБ, не может быть сохранена в виде единого документа?

Также это также считает вложенные документы?

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

Надеюсь, что кто-то объяснит это правильно.

Я только что начал читать о MongoDB (первая база данных nosql, о которой я узнал).

Спасибо.

saint 12 янв. 2011, в 10:07

Источник

5

Я думаю, что вопрос должен прояснить, что это ограничение размеров хранимых документов MongoDB, а не формата BSON.
alexpopescu 12 янв. 2011, в 14:03
2

@alexpopescu, ты прав.
saint 12 янв. 2011, в 14:48
2

Хотя я только что попытался сохранить огромный документ, который наверняка превышает 4 МБ, чтобы получить сообщение «BSON :: InvalidDocument: слишком большой документ: документы BSON ограничены 4194304 байтами». Если это так, разве это не вводит в заблуждение в предупреждении / сообщении об ошибке?
Nik So 24 фев. 2011, в 19:21
18

Вы можете легко найти ваш максимальный размер документа BSON с помощью команды db.isMaster().maxBsonObjectSize/(1024*1024)+' MB' в оболочке mongo .
AhmetB - Google 28 окт. 2011, в 16:39
4

Какова цель nosql без схемы, где вы не можете записывать записи размером более 16 МБ и строить поверх него операции crud!
Rizwan Patel 19 авг. 2016, в 11:17
0

Я думаю, что первоначальная цитата говорит само за себя ... Ограничение установлено, чтобы предотвратить плохой дизайн схемы. Если, например, у вас есть сообщение с большим количеством комментариев, вам понадобится коллекция записей в блоге и коллекция комментариев или коллекция изменений. Конструкция mongo / nosql позволяет создавать объекты большого размера в виде сетей документов, но разработчику необходимо разбить их на части, которые имеют смысл. Если ограничение размера не установлено, возникнут другие проблемы. Я думаю, что ограничение 4 Мб было хорошо. 16mb, отлично! Но если я пишу документ размером 16 Мб, это признак того, что с дизайном что-то не так.
The Molecule 09 апр. 2018, в 12:27

Показать ещё 4 комментария

Теги:

mongodb

bson

6 ответов

23

Многие в сообществе не предпочтут никаких ограничений с предупреждениями о производительности, см. этот комментарий для аргумента с обоснованной аргументацией: https://jira.mongodb.org/browse/SERVER-431?focusedCommentId=22283&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-22283

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

marr75 10 июль 2012, в 19:48

4

Я полностью согласен с вами, так как теперь это противоречит цели встраивания документов, так как большинство встроенных документов теперь легко пересекают границы. Esp с массивом документов внутри них
Sharjeel Ahmed 15 фев. 2016, в 08:43
0

@ marr75 сейчас написано исправлено, исправлено?
Mafii 27 апр. 2016, в 07:11
1

Я имею в виду, предел был увеличен до 16 МБ, что не решает проблему в долгосрочной перспективе; ИМО предел должен быть просто устранен.
marr75 02 июнь 2016, в 18:56
1

6 лет нить некро. Я совершенно не убежден в вашем конкретном неудачном примере использования / примере дизайна. Кроме того, этот пример гораздо лучше иллюстрирует необходимость проверки входных данных, чем ограничение размера одного документа в базе данных. Заставить приложение разделить вложенные документы как отдельные документы в другой коллекции или запустить новый документ «продолжение» (решения, которые я использовал несколько раз для работы в рамках этого лимита) оказало небольшое влияние на производительность, но сильно сказалось на сложности кода. Весь смысл БД документов - локальность данных.
marr75 24 май 2018, в 18:46
0

Добавление дополнительных 2 ¢, подобное ограничение, на самом деле, «не отменяет цели» встроенных документов. Мои игровые форумы, например, хранят все ответы в ветке. Чтобы превысить текущий предел в 16 МБ, сообщество должно написать роман, содержащий более 500 глав в одном потоке - этого не произойдет . (6,5 средних байтов на слово, длина главы 5К слов.)
amcgregor 26 март 2019, в 16:03

Показать ещё 3 комментария

18

Опубликовать ответ на разъяснение здесь для тех, кто направляется сюда Google.

Размер документа включает все документы, включая поддокументы, вложенные объекты и т.д.

Итак, документ:

{
    _id:{},
    na: [1,2,3],
    naa: [
        {w:1,v:2,b:[1,2,3]},
        {w:5,b:2,h:[{d:5,g:7},{}]}
    ]
}

Максимальный размер 16 мг.

Sbudocuments и вложенные объекты подсчитываются по размеру документа.

Sammaye 16 окт. 2013, в 11:44

0

По иронии судьбы, самая большая структура, которая может быть представлена в BSON, также является самой компактной. Несмотря на то, что MongoDB внутренне использует индексы массива size_t (64-разрядные), ограничение размера документа в 16 МБ в лучшем случае сможет представлять собой документ, содержащий сам один массив, содержащий два миллиона NULL.
amcgregor 26 март 2019, в 16:14
0

Извиняюсь, добавив второй комментарий, чтобы прояснить / уточнить еще одну важную деталь: когда вы говорите, что размер документа включает в себя все, что есть в документе , это также включает и ключи . Например, {"f": 1} на два байта меньше, чем {"foo": 1} . Это может быстро сложиться, если вы не будете осторожны, хотя современное сжатие на диске помогает.
amcgregor 26 март 2019, в 16:17

5

Вложенная глубина для документов BSON: MongoDB поддерживает не более 100 уровней вложения для документов BSON.

Больше информации vist

user2903536 17 апр. 2016, в 05:31

3

Я еще не видел проблемы с лимитом, который не включал большие файлы, хранящиеся в самом документе. Уже существует множество баз данных, которые очень эффективны при хранении/извлечении больших файлов; они называются операционными системами. База данных существует как слой поверх операционной системы. Если вы используете решение NoSQL по соображениям производительности, почему вы хотите добавить дополнительные служебные данные для обработки ваших данных, поместив уровень БД между вашим приложением и вашими данными?

JSON - это текстовый формат. Таким образом, если вы получаете доступ к своим данным через JSON, это особенно актуально, если у вас есть двоичные файлы, потому что они должны быть закодированы в uuencode, шестнадцатеричном или Base 64. Путь преобразования может выглядеть как

двоичный файл < > JSON (закодированный) < > BSON (закодированный)

Было бы более удобно поместить путь (URL) в файл данных в вашем документе и сохранить сами данные в двоичном формате.

Если вы действительно хотите хранить эти файлы с неизвестной длиной в своей базе данных, то вам, вероятно, будет лучше помещать их в GridFS и не рискует убить ваш concurrency при доступе к большим файлам.

Chris Golledge 20 июнь 2013, в 22:18

1

«Уже существует множество баз данных, которые очень эффективны для хранения / извлечения больших файлов; они называются операционными системами.»; См. Blog.mongodb.org/post/183689081/…
redcalx 13 июль 2015, в 12:01

1

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

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

[править]

См. комментарии ниже для дальнейшего обсуждения.

Mchl 12 янв. 2011, в 11:50

0

Не знаю о лучшем дизайне на этой ранней стадии опыта. Книга дает небольшой пример блога. Отсюда и мысль. Благодарю.
saint 12 янв. 2011, в 10:30
14

Я совсем не согласен. Комментарии в ваших публикациях в блоге должны быть в порядке в MongoDB ... это очень распространенное использование (я использую его более чем в одном месте, и оно работает довольно хорошо).
Justin Jenkins 12 янв. 2011, в 10:34
0

@Justin Jenkins: Я согласен с вами, но это действительно зависит от сайта. Поэтому я верю, что для таких сайтов, как stackoverflow, необходимо создать отдельный документ для комментариев.
Andrew Orsich 12 янв. 2011, в 10:38
0

@ Bugai13 ... да, конечно, но 98% сайтов совсем близко от этого :) Это все, что я говорю. Для большинства сайтов это будет отлично работать (и, возможно, на самом деле ПОМОЖЕТ больше, чем могло бы повредить). Тем не менее, в зависимости от вашей шкалы, хранение комментариев в отдельной коллекции может быть единственным вариантом.
Justin Jenkins 12 янв. 2011, в 10:41
2

Возможно, я был слишком строг в своем ответе. Нет ничего плохого в хранении постов в блоге и связанных комментариев в MongoDB или аналогичной базе данных. Более того, люди склонны злоупотреблять возможностями баз данных на основе документов (наиболее радикальный пример - хранить все ваши данные в одном документе под названием «блог»).
Mchl 12 янв. 2011, в 10:44
0

@Justin: я снова согласен ... Но еще одна вещь. Дизайн документа db также зависит от дизайна сайта, потому что если вам нужно отобразить список тем без комментариев (например, список вопросов в stackoverflow), то наверняка нужно создать отдельные документы для блога и комментариев.
Andrew Orsich 12 янв. 2011, в 10:46
0

@Mchl полностью согласен на злоупотребления! «Блог» документ был бы безумным. :)
Justin Jenkins 12 янв. 2011, в 10:47
0

@ Bugai13 Я, возможно, не совсем понимаю, что вы говорите, но я думаю, что на самом деле это довольно простой запрос MongoDB: «отобразить список тем без комментариев». Тем не менее, я думаю, что я понимаю вашу точку зрения.
Justin Jenkins 12 янв. 2011, в 10:54
2

@Mchel: «блог» - это нехорошо, но хранить комментарии в отдельной коллекции так же плохо по тем же причинам. Сообщения с массивом комментариев, как, канонический пример документа БД.
Matt Briggs 12 янв. 2011, в 14:51
6

@SoPeople: хранение комментариев внутри поста похоже на канонический пример документно-ориентированных баз данных. (как хранение всего текста вики внутри одного документа) Если бы я написал SO, он бы полностью работал на MongoDB. Ни одна из этих записей SO не будет разумно превышать 4 МБ. Craigslist делает гигантскую миграцию БД своей истории в MongoDB. У них было только несколько документов, превышающих этот лимит, и ведущий разработчик предположил, что сами документы действительно были повреждены (результат некоторых ошибок). Опять же 4 мег это несколько романов текста.
Gates VP 12 янв. 2011, в 23:21
0

@Gates VP, я согласен!
TTT 13 янв. 2011, в 19:54
0

@Gates VP, как насчет поиска тегов? Получение результатов поиска будет достаточно быстрым для SO, но для сайта, на котором много больших документов, вам может потребоваться загрузить и передать мегабайты данных.
mikerobi 07 июнь 2011, в 14:42
0

@mikerobi: это ограничение 4 МБ (теперь 16 МБ) для одного документа. Помните, что в MongoDB «документ» примерно эквивалентен «строке». Если у вас большие бинарные объекты, вам следует взглянуть на GridFS для хранения этих объектов. Если вам нужно искать в больших объемах простого текста И этот текст превышает 4 МБ, то MongoDB не является правильным инструментом (как и большинство БД). Для поиска по большому количеству текста, пожалуйста, посмотрите на SOLR или Sphinx.
Gates VP 07 июнь 2011, в 15:26
3

@Gates VP, я согласен на использование отдельного полнотекстового движка. Я думал о поиске метаданных. Что, если у вас есть набор Книжных документов, и вы хотите найти все книги, изданные в 1982 году? Если каждая книга содержит + 100 КБ текста, вы не хотите передавать несколько мегабайт только для отображения первых 20 названий книг.
mikerobi 07 июнь 2011, в 16:43

Показать ещё 12 комментариев

Ещё вопросы

Я думаю, что вопрос должен прояснить, что это ограничение размеров хранимых документов MongoDB, а не формата BSON.
Хотя я только что попытался сохранить огромный документ, который наверняка превышает 4 МБ, чтобы получить сообщение «BSON :: InvalidDocument: слишком большой документ: документы BSON ограничены 4194304 байтами». Если это так, разве это не вводит в заблуждение в предупреждении / сообщении об ошибке?
Вы можете легко найти ваш максимальный размер документа BSON с помощью команды db.isMaster().maxBsonObjectSize/(1024*1024)+' MB' в оболочке mongo .
Какова цель nosql без схемы, где вы не можете записывать записи размером более 16 МБ и строить поверх него операции crud!
Я думаю, что первоначальная цитата говорит само за себя ... Ограничение установлено, чтобы предотвратить плохой дизайн схемы. Если, например, у вас есть сообщение с большим количеством комментариев, вам понадобится коллекция записей в блоге и коллекция комментариев или коллекция изменений. Конструкция mongo / nosql позволяет создавать объекты большого размера в виде сетей документов, но разработчику необходимо разбить их на части, которые имеют смысл. Если ограничение размера не установлено, возникнут другие проблемы. Я думаю, что ограничение 4 Мб было хорошо. 16mb, отлично! Но если я пишу документ размером 16 Мб, это признак того, что с дизайном что-то не так.
Я полностью согласен с вами, так как теперь это противоречит цели встраивания документов, так как большинство встроенных документов теперь легко пересекают границы. Esp с массивом документов внутри них
@ marr75 сейчас написано исправлено, исправлено?
Я имею в виду, предел был увеличен до 16 МБ, что не решает проблему в долгосрочной перспективе; ИМО предел должен быть просто устранен.
6 лет нить некро. Я совершенно не убежден в вашем конкретном неудачном примере использования / примере дизайна. Кроме того, этот пример гораздо лучше иллюстрирует необходимость проверки входных данных, чем ограничение размера одного документа в базе данных. Заставить приложение разделить вложенные документы как отдельные документы в другой коллекции или запустить новый документ «продолжение» (решения, которые я использовал несколько раз для работы в рамках этого лимита) оказало небольшое влияние на производительность, но сильно сказалось на сложности кода. Весь смысл БД документов - локальность данных.
Добавление дополнительных 2 ¢, подобное ограничение, на самом деле, «не отменяет цели» встроенных документов. Мои игровые форумы, например, хранят все ответы в ветке. Чтобы превысить текущий предел в 16 МБ, сообщество должно написать роман, содержащий более 500 глав в одном потоке - этого не произойдет . (6,5 средних байтов на слово, длина главы 5К слов.)
По иронии судьбы, самая большая структура, которая может быть представлена в BSON, также является самой компактной. Несмотря на то, что MongoDB внутренне использует индексы массива size_t (64-разрядные), ограничение размера документа в 16 МБ в лучшем случае сможет представлять собой документ, содержащий сам один массив, содержащий два миллиона NULL.
Извиняюсь, добавив второй комментарий, чтобы прояснить / уточнить еще одну важную деталь: когда вы говорите, что размер документа включает в себя все, что есть в документе , это также включает и ключи . Например, {"f": 1} на два байта меньше, чем {"foo": 1} . Это может быстро сложиться, если вы не будете осторожны, хотя современное сжатие на диске помогает.
«Уже существует множество баз данных, которые очень эффективны для хранения / извлечения больших файлов; они называются операционными системами.»; См. Blog.mongodb.org/post/183689081/…
Не знаю о лучшем дизайне на этой ранней стадии опыта. Книга дает небольшой пример блога. Отсюда и мысль. Благодарю.
Я совсем не согласен. Комментарии в ваших публикациях в блоге должны быть в порядке в MongoDB ... это очень распространенное использование (я использую его более чем в одном месте, и оно работает довольно хорошо).
@Justin Jenkins: Я согласен с вами, но это действительно зависит от сайта. Поэтому я верю, что для таких сайтов, как stackoverflow, необходимо создать отдельный документ для комментариев.
@ Bugai13 ... да, конечно, но 98% сайтов совсем близко от этого :) Это все, что я говорю. Для большинства сайтов это будет отлично работать (и, возможно, на самом деле ПОМОЖЕТ больше, чем могло бы повредить). Тем не менее, в зависимости от вашей шкалы, хранение комментариев в отдельной коллекции может быть единственным вариантом.
Возможно, я был слишком строг в своем ответе. Нет ничего плохого в хранении постов в блоге и связанных комментариев в MongoDB или аналогичной базе данных. Более того, люди склонны злоупотреблять возможностями баз данных на основе документов (наиболее радикальный пример - хранить все ваши данные в одном документе под названием «блог»).
@Justin: я снова согласен ... Но еще одна вещь. Дизайн документа db также зависит от дизайна сайта, потому что если вам нужно отобразить список тем без комментариев (например, список вопросов в stackoverflow), то наверняка нужно создать отдельные документы для блога и комментариев.
@Mchl полностью согласен на злоупотребления! «Блог» документ был бы безумным. :)
@ Bugai13 Я, возможно, не совсем понимаю, что вы говорите, но я думаю, что на самом деле это довольно простой запрос MongoDB: «отобразить список тем без комментариев». Тем не менее, я думаю, что я понимаю вашу точку зрения.
@Mchel: «блог» - это нехорошо, но хранить комментарии в отдельной коллекции так же плохо по тем же причинам. Сообщения с массивом комментариев, как, канонический пример документа БД.
@SoPeople: хранение комментариев внутри поста похоже на канонический пример документно-ориентированных баз данных. (как хранение всего текста вики внутри одного документа) Если бы я написал SO, он бы полностью работал на MongoDB. Ни одна из этих записей SO не будет разумно превышать 4 МБ. Craigslist делает гигантскую миграцию БД своей истории в MongoDB. У них было только несколько документов, превышающих этот лимит, и ведущий разработчик предположил, что сами документы действительно были повреждены (результат некоторых ошибок). Опять же 4 мег это несколько романов текста.
@Gates VP, как насчет поиска тегов? Получение результатов поиска будет достаточно быстрым для SO, но для сайта, на котором много больших документов, вам может потребоваться загрузить и передать мегабайты данных.
@mikerobi: это ограничение 4 МБ (теперь 16 МБ) для одного документа. Помните, что в MongoDB «документ» примерно эквивалентен «строке». Если у вас большие бинарные объекты, вам следует взглянуть на GridFS для хранения этих объектов. Если вам нужно искать в больших объемах простого текста И этот текст превышает 4 МБ, то MongoDB не является правильным инструментом (как и большинство БД). Для поиска по большому количеству текста, пожалуйста, посмотрите на SOLR или Sphinx.
@Gates VP, я согласен на использование отдельного полнотекстового движка. Я думал о поиске метаданных. Что, если у вас есть набор Книжных документов, и вы хотите найти все книги, изданные в 1982 году? Если каждая книга содержит + 100 КБ текста, вы не хотите передавать несколько мегабайт только для отображения первых 20 названий книг.

Justin Jenkins · Accepted Answer · 2011-01-12T10-32-00.000Z

Во-первых, это в настоящее время поднимается в следующей версии до 8MB или 16MB... но я думаю, чтобы это было в перспективе, Элиот из 10gen (кто разработал MongoDB) ставит его лучше:

EDIT: Размер официально 'поднят' до 16MB

Итак, на примере вашего блога 4MB на самом деле много. Например, полный текст стиха "Война Миры" всего 364k (html): http://www.gutenberg.org/etext/36

Если ваш пост в блоге так долго что многие комментарии, я для меня не прочитав это:)

Для трекбэков, если вы выделили 1 МБ к ним вы могли бы легко получить больше чем 10k (вероятно, ближе к 20k)

Итак, за исключением поистине странных ситуации, это будет отлично работать. И в случай исключения или спам, я действительно не думайте, что вам нужен объект 20mb так или иначе. Я думаю, 15k или около того имеет большой смысл нет вопрос, что для исполнения. Или в наименее специальный корпус, если он когда-либо случается.

-Eliot

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

Основная точка префикса заключается в том, что вы не используете всю RAM на своем сервере (так как вам нужно загрузить все MB документа в ОЗУ при его запросе.)

Таким образом, предел - это некоторый процент нормальной полезной ОЗУ на общей системе..., которая будет расти с каждым годом.

Примечание по сохранению файлов в MongoDB

Если вам нужно хранить документы (или файлы) больше, чем 16MB, вы можете использовать GridFS API, который автоматически разбивает данные в сегменты и передать их обратно вам (таким образом, избежать проблемы с ограничениями по размеру/оперативной памяти).

Вместо хранения файла в одном документе GridFS делит файл на части или куски и сохраняет каждый кусок в виде отдельного документа.

GridFS использует две коллекции для хранения файлов. Одна коллекция хранит фрагменты файлов, а другая хранит метаданные файлов.

Этот метод можно использовать для хранения изображений, файлов, видео и т.д. в базе данных так же, как и в базе данных SQL. Я использовал это для хранения видеофайлов с несколькими гигабайтами.

Я не очень понимаю, «главное ограничение - чтобы вы не использовали всю оперативную память на вашем сервере». Мы храним всю нашу базу данных MongoDB в оперативной памяти, так что это все еще проблема?
Удивительно, что у вас достаточно ОЗУ для всей вашей базы данных ... Обычно «рабочий набор» находится в ОЗУ, а не во всей базе данных (как в моем случае, у меня более одной базы данных по x ГБ, где, если все сложение будет превышать мою ОЗУ, но это нормально, потому что рабочий набор намного, намного меньше.) Кроме того, если бы не было предела, вы могли бы загрузить документ объемом 800 МБ в ОЗУ с одним запросом и документ объемом 400 КБ с другим, что немного затруднило бы балансировку ОЗУ и т. д. Таким образом, «лимит» составляет несколько% от типичной оперативной памяти сервера (таким образом, она увеличивается со временем.) Mongodb.org/display/DOCS/Checking+Server+Memory+Usage
Здорово, что вы можете хранить все в оперативной памяти, но учитывайте эффективность и идиому в блоге. Вы, очевидно, хотите, чтобы сообщение было в памяти, если оно прочитано. Но действительно ли вы хотите, чтобы 10 страниц комментариев для поста блога оставались в памяти, когда большинство людей никогда не будут читать мимо первой страницы? Конечно, вы можете сделать это, и если ваша база данных достаточно мала, чтобы она могла вместиться в память, тогда проблем нет. Но с точки зрения чистой эффективности, вы не хотите, чтобы бесполезные биты занимали место в памяти, если вы можете этого избежать (и это касается и RDBMS).
милый Иисус, так что аргумент Монго таков: "16 МБ должно быть достаточно для всех"? Это не похоже на то, что когда-либо было неверным в прошлом.
Было бы неплохо, если бы был пример того, как справиться с такой ситуацией. Можно предположить, что можно легко превысить 16 МБ, если файлы (например, изображения и т. Д.) Также были разрешены в комментариях приложения.
Это кажется слишком плохим для меня. Mongo должен быть полезен для больших данных, не иметь таких ограничений. В моем проекте мне нужно объединить и сгруппировать твиты, связанные с одной и той же тенденцией, и это может закончиться более чем 20000 твитами за период времени в 20 часов (и вполне возможно, что тренды будут длиться дольше, чем 20 часов в моем БД). Наличие такого большого количества твитов и одновременного хранения их текста является разрушительным, и после группировки нескольких небольших трендов это заканчивается исключением большого тренда.
@Savvas прав в том, что является целью 16 МБ для системы без схемы nosql. Мы понимаем, почему существует ограничение в 16 МБ, но альтернатива сценарию реального мира заключается в том, что мы распределяем данные по различным документам и применяем связи для работы в формате crud, как вы знаете в обычной системе rdbms. !
@savvas, почему бы тебе поместить все твиты в один документ? Используйте один документ на твит, добавьте тему обсуждения в качестве другого поля в документе. поместите индекс в это поле темы и затем агрегируйте в этом поле, используя конвейер Монго. чтобы настроить nosql, нужно внести некоторые коррективы в то, как вы настроите свои методы и решите, что он отлично работает для многих случаев использования больших данных.
@schmidlop Я не совсем помню сейчас, но я думаю, что это то, что я сделал. Но когда я агрегировал в поле темы, он создавал отдельный документ для каждого ключа и получал огромные документы по самым большим темам. Во всяком случае, это было в прошлом году, и я едва помню свою реализацию: P