Mongodb сколько занимает памяти
Документы размером более 4 МБ (при преобразовании в BSON) не могут быть сохранены в базе данных. Это несколько произвольный предел (и может быть повышен в будущем); это в основном для предотвращения неправильного проектирования схемы и обеспечения стабильной производительности.
Также учитывает ли это вложенные документы?
Что делать, если я хотел документ, который проверяет изменения стоимости. (В конечном итоге он может возрасти, превысив предел 4 МБ.)
Надеюсь, кто-то объясняет это правильно.
Я только начал читать о MongoDB (первая база данных nosql, о которой я узнаю).
Я думаю, что вопрос должен прояснить, что это ограничение размеров хранимых документов MongoDB, а не формата BSON.
Вы можете легко найти ваш максимальный размер документа BSON с помощью db.isMaster().maxBsonObjectSize/(1024*1024)+' MB' команды в mongo оболочке.
Какова цель nosql без схемы, где вы не можете записывать записи размером более 16 МБ и строить поверх него операции crud!
Во-первых, это на самом деле поднимается в следующей версии 8MB или 16MB . но я думаю, чтобы представить это в перспективе, Элиот из 10gen (который разработал MongoDB) считает это лучше:
РЕДАКТИРОВАТЬ: размер был официально "поднят" до 16MB
Я думаю, что вам будет довольно трудно достичь предела . и со временем, если вы обновитесь . вам придется беспокоиться все меньше и меньше.
Суть ограничения заключается в том, что вы не используете всю оперативную память на своем сервере (так как вам нужно загрузить все MB документы в оперативную память при запросе).
Таким образом, ограничение составляет несколько% от нормальной используемой оперативной памяти в общей системе . которая будет расти из года в год.
Замечание о хранении файлов в MongoDB
Если вам нужно хранить документы (или файлы) больше, чем 16MB вы можете использовать GridFS API, который автоматически разбивает данные на сегменты и направляет их обратно вам (таким образом, избегая проблемы с ограничениями размера / оперативной памяти.)
Вместо того, чтобы хранить файл в одном документе, GridFS делит файл на части или порции и сохраняет каждый фрагмент как отдельный документ.
GridFS использует две коллекции для хранения файлов. В одной коллекции хранятся фрагменты файлов, а в другой - метаданные файлов.
Вы можете использовать этот метод для хранения изображений, файлов, видео и т. Д. В базе данных так же, как в базе данных SQL. Я использовал это, чтобы даже хранить мульти гигабайтные видеофайлы.
милый Иисус, так что аргумент Монго таков: "16 МБ должно быть достаточно для всех"? Это не похоже на то, что когда-либо было неверным в прошлом.
Это кажется слишком плохим для меня. Mongo должен быть полезен для больших данных, не иметь таких ограничений. В моем проекте мне нужно объединить и сгруппировать твиты, связанные с одной и той же тенденцией, и это может закончиться более чем 20000 твитами за период времени в 20 часов (и вполне возможно, что тренды будут длиться дольше, чем 20 часов в моем БД). Наличие такого большого количества твитов и одновременное хранение их текста является разрушительным, а после группировки нескольких небольших трендов это заканчивается исключением большого тренда.
@savvas, почему бы тебе поместить все твиты в один документ? Используйте один документ на твит, добавьте тему обсуждения в качестве другого поля в документе. поместите индекс в это поле темы и затем агрегируйте в этом поле, используя конвейер Монго. чтобы настроить nosql, нужно внести некоторые коррективы в то, как вы настроите свои методы и решите, что он отлично работает для многих случаев использования больших данных.
На мой взгляд, ведущие разработчики упрямы в этом вопросе, потому что они решили, что это важная «особенность» на раннем этапе. Они не собираются менять это в ближайшее время, потому что их чувства обижены тем, что кто-то подверг сомнению это. Еще один пример того, как личность и политика отвлекают от продукта в сообществах с открытым исходным кодом, но это не является серьезной проблемой.
Я полностью согласен с вами, так как в настоящее время это противоречит цели встраивания документов, поскольку большинство встроенных документов теперь легко пересекают границы. Esp с множеством документов внутри них
Я имею в виду, предел был увеличен до 16 МБ, что не решает проблему в долгосрочной перспективе; ИМО предел должен быть просто устранен.
6 лет нить некро. Я совершенно не убежден в вашем конкретном неудачном примере использования / примере дизайна. Кроме того, этот пример гораздо лучше иллюстрирует необходимость проверки входных данных, чем ограничение размера одного документа в базе данных. Заставить приложение разделить вложенные документы как отдельные документы в другой коллекции или запустить новый документ «продолжения» (решения, которые я использовал несколько раз для работы в рамках этого лимита), мало повлияло на производительность, но сильно повлияло на сложность кода. Весь смысл БД документов - локальность данных.
Спасибо за выполнение той же математики, что и документы mongoDB, чтобы защитить это решение, но ваш единственный вариант использования и мысленный эксперимент далеко не окончательны. Мне пришлось придумать сложные, избыточные конструкции, чтобы обойти тот факт, что существует произвольный предел, который попадает под действие монго (без глубоко вложенных или дублированных записей, кстати). По вашей логике, ни одна база данных не должна содержать более 16 МБ общего объема, поскольку некоторый произвольный текст может быть представлен с использованием меньшего объема памяти. Это явно глупо.
Чтобы опубликовать разъясняющий ответ здесь для тех, кто направляется сюда от Google.
Размер документа включает в себя все в документе, включая вложенные документы, вложенные объекты и т. Д.
Итак, документ о:
Максимальный размер 16мг.
Вложенные документы и вложенные объекты учитываются по размеру документа.
По иронии судьбы, самая большая структура, которая может быть представлена в BSON, также является самой компактной. Несмотря на то, что MongoDB использует size_t (64-битные) индексы массивов внутри, предельный размер документа в 16 МБ, в лучшем случае, сможет представлять документ, содержащий сам один массив, содержащий два миллиона NULL.
Извиняюсь, добавив второй комментарий, чтобы прояснить / уточнить еще одну важную деталь: когда вы говорите, что размер документа включает в себя все, что есть в документе , это также включает и ключи . Например, на два байта меньше, чем . Это может быстро сложиться, если вы не будете осторожны, хотя современное сжатие на диске помогает.
Я еще не видел проблемы с лимитом, который не затрагивал большие файлы, хранящиеся в самом документе. Уже существует множество баз данных, которые очень эффективны для хранения / извлечения больших файлов; они называются операционными системами. База данных существует как слой над операционной системой. Если вы используете решение NoSQL по соображениям производительности, почему вы хотите добавить дополнительные издержки обработки к доступу к вашим данным, поместив слой БД между вашим приложением и вашими данными?
JSON - это текстовый формат. Итак, если вы обращаетесь к своим данным через JSON, это особенно верно, если у вас есть двоичные файлы, потому что они должны быть закодированы в uuencode, шестнадцатеричном или Base 64. Путь преобразования может выглядеть следующим образом
двоичный файл <> JSON (кодированный) <> BSON (кодированный)
Было бы эффективнее поместить путь (URL) к файлу данных в вашем документе и сохранить сами данные в двоичном виде.
Если вы действительно хотите сохранить эти файлы неизвестной длины в вашей БД, то вам, вероятно, лучше поместить их в GridFS и не рисковать уничтожением параллелизма при обращении к большим файлам.
Вложенная глубина для документов BSON: MongoDB поддерживает не более 100 уровней вложенности для документов BSON.
Люди, которые использовали MongoDB, должны найти проблему, заключающуюся в том, что со временем физическая память, занимаемая MongoDB, будет становиться все больше и больше, даже достигая невообразимых уровней. Или за короткий промежуток времени производительность MongoDB тестируется со стрессом, память будет очень высокой, и она всегда будет оставаться на самом высоком уровне.
На моей виртуальной машине был выполнен следующий тест: конфигурация 1 core 4G, инструмент стресс-теста YCSB и команда test
./bin/ycsb load mongodb -s -P workloads/workloada -threads 50 > outputLoad.txt
./bin/ycsb run mongodb -s -P workloads/workloada -threads 50 > outputRun.txt
Общий объем данных теста в файле рабочей нагрузки был изменен на 100 Вт. Результаты теста следующие:
Можно видеть, что MongoDB занимает 33,5% памяти, хотя она составляет всего 1,3 ГБ, но доля, занятая на серверах 32 ГБ, также может достигать 30% ~ 40%, что составляет около 10 ГБ, что легко повлияет на нормальную работу других процессов.
Смотрите официальный сайт о памяти:
Memory Use
With WiredTiger, MongoDB utilizes both the WiredTiger internal cache and the filesystem cache.
Starting in 3.4, the WiredTiger internal cache, by default, will use the larger of either:
By default, WiredTiger uses Snappy block compression for all collections and prefix compression for all indexes. Compression defaults are configurable at a global level and can also be set on a per-collection and per-index basis during collection and index creation.
Different representations are used for data in the WiredTiger internal cache versus the on-disk format:
- Data in the filesystem cache is the same as the on-disk format, including benefits of any compression for data files. The filesystem cache is used by the operating system to reduce disk I/O.
- Indexes loaded in the WiredTiger internal cache have a different data representation to the on-disk format, but can still take advantage of index prefix compression to reduce RAM usage. Index prefix compression deduplicates common prefixes from indexed fields.
- Collection data in the WiredTiger internal cache is uncompressed and uses a different representation from the on-disk format. Block compression can provide significant on-disk storage savings, but data must be uncompressed to be manipulated by the server.
Via the filesystem cache, MongoDB automatically uses all free memory that is not used by the WiredTiger cache or by other processes.
To adjust the size of the WiredTiger internal cache, see storage.wiredTiger.engineConfig.cacheSizeGB and --wiredTigerCacheSizeGB . Avoid increasing the WiredTiger internal cache size above its default value.
Начиная с версии 3.4, внутренний кэш WieldGigd будет использовать больший из следующих двух по умолчанию: 50% (RAM-1 ГБ) и 256 МБ. При кэшировании файловой системы автоматическое использование MongoDB не кэшируется wiredtiger и не используется всеми процессами для всей доступной памяти. Методы настройки внутреннего кэша WiredTiger: storage.wiredTiger.engineConfig.cacheSizeGB и --wiredTigerCacheSizeGB
Похоже, что если не установить, 50% (RAM-1 ГБ) памяти будет использоваться по умолчанию. Поэтому установите для storage.wiredTiger.engineConfig.cacheSizeGB в файле конфигурации значение 0,5, что составляет 500 МБ, а затем посмотрите результаты теста:
Видно, что физическая память, занимаемая MongoDB, стабильна на уровне около 630 МБ, что указывает на то, что настройка действительно вступила в силу.
Нажмите три числа от большого до небольшого выхода
LeetCode: Интервью 04.04. Проверьте баланс
Глубокоищите дерево, получите высоту левого поддерева и правого поддерева, если две разницы высоты превышают 1, это не дерево баланса .
Интеллектуальная рекомендация
Освободите место на диске после удаления данных MongoDB
mognodb не освобождает занятое место на диске в случае удаления данных, даже удаления коллекции, если только база данных не удалена.
То есть, когда память, занимаемая mongodb, составляет 10 ГБ, после удаления данных 8 ГБ размер файла данных по-прежнему составляет 10 ГБ. Команда "df", чтобы увидеть, что объем памяти не изменился.
Обычно вы можете отслеживать использование памяти MongoDB через командную строку mongo, как показано ниже:
> Вы также можете отслеживать использование памяти MongoDB с помощью команды mongostat, как показано ниже:
mapped vsize res faults
940g 1893g 21.9g 0
Значение полей, связанных с памятью:
сопоставленный: размер данных, сопоставленных с памятью
visze: размер виртуальной памяти
res: объем используемой физической памяти
Примечание. Если операция не может быть завершена в памяти, значение столбца ошибок не будет равно 0, в зависимости от размера могут возникнуть проблемы с производительностью.
В приведенном выше результате, vsize в два раза больше размера сопоставленного, а сопоставленный равен размеру файла данных, поэтому vsize в два раза больше размера файла данных.
Причина этого заключается в том, что в этом примере MongoDB имеет включенный журнал, и файл данных необходимо снова отобразить в памяти. Если вы выключите журнал,
Тогда vsize и mapped примерно эквивалентны.
1. Убедитесь, что объем памяти изменился с помощью команды db.serverStatus (). Mem после удаления данных:
Посмотреть след памяти Монго:
Просмотр системной памяти:
Используйте сценарии для вставки больших объемов данных в монго.
После удаления вставленных данных:
Вывод: удаление данных в коллекции не освободит дисковое пространство;
Используйте команду dbshell, чтобы проверить использование памяти и показать, что она была освобождена;
Память вида оболочки Linux не была выпущена
Введите БД с удаленными данными и используйте db.repairDatabase ():
Дисковая память была освобождена.
repairDatabase - единственный метод в официальной документации, который может освободить место на жестком диске.
repairDatabase is the appropriate and the only way to reclaim disk space.
Хотя вы можете использовать db.repairDatabase () для восстановления данных. Но у этого метода есть два недостатка. 1. Эксплуатация в производственном процессе может привести к невозможности восстановления данных при случайной остановке. 2. Если места на диске недостаточно, меньше, чем занимаемое текущее время в БД, db.repairDatabase () не может быть использовано в этом случае.
Обратите внимание, что свободное место на диске, необходимое для операции repairDatabase, равно текущему общему объему данных плюс 2G. Если текущего дискового пространства недостаточно, вы можете попытаться указать путь к разделу с достаточным пространством, используя параметр –repairpath.
Проверьте, можете ли вы использовать команду db.repairDatabase () для освобождения занятого пространства памяти, когда использование памяти превышает 50%:
1. Свободной памяти меньше текущей оставшейся памяти:
После удаления данных:
Вывод: освобожденная память меньше текущей оставшейся памяти, и выпуск выполнен успешно.
2. Освободившаяся память больше текущей памяти:
После удаления данных:
Невозможно освободить память
Python использует монго для освобождения места:
Передайте команду db.repairDatabase () на монго.
Обучение HTML-записи (1)
Ссылки на учебные ресурсы Обучающее видео html element label значение периодической таблицы элементов Документ Знания чаевые единый формат HTML содержание имя тега> Теги могут.
Этот вопрос был перенесен из переполнения стека, поскольку на него можно ответить в Exchange Stack Exchange для администраторов баз данных. Мигрировал 3 года назад .
Мы используем MongoDB уже несколько недель, общая тенденция, которую мы видели, заключается в том, что mongodb использует слишком много памяти (намного больше, чем весь размер его набора данных + индексы).
Я уже прочитал этот вопрос и этот вопрос , но, похоже, никто не решает проблему, с которой я столкнулся, они фактически объясняют то, что уже объяснено в документации.
Ниже приведены результаты команд htop и show dbs .
Я знаю, что mongodb использует IO с отображением в памяти, поэтому в основном ОС обрабатывает кэширование в памяти, и mongodb должен теоретически освобождать свою кэшированную память, когда другой процесс запрашивает свободную память , но, как мы видели, это не так.
OOM начинает работу, убивая другие важные процессы, такие как postgres, redis и т. Д. (Как можно видеть, чтобы преодолеть эту проблему, мы увеличили объем ОЗУ до 183 ГБ, который сейчас работает, но довольно дорогой. Монго использует ~ 87 ГБ ОЗУ, почти в 4 раза больше, чем весь его набор данных)
- Действительно ли такое потребление памяти ожидается и нормально? (Согласно документации, WiredTiger использует максимум ~ 60% оперативной памяти для своего кэша, но, учитывая размер набора данных, достаточно ли данных для того, чтобы можно было использовать 86 ГБ оперативной памяти?)
- Даже если ожидается использование памяти, почему mongo не отпустит выделенную память, если другой процесс начнет запрашивать больше памяти? Различные другие запущенные процессы были постоянно убиты linux oom, включая сам mongodb, прежде чем мы увеличили объем оперативной памяти, и это сделало систему совершенно нестабильной.
Итак, после следования подсказкам, данным loicmathieu и jstell, и немного покопав их, вот что я узнал о MongoDB, используя механизм хранения WiredTiger. Я ставлю это здесь, если кто-то сталкивался с такими же вопросами.
Потоки памяти, о которых я упоминал, все принадлежали 2012-2014 годам , все предшествующие WiredTiger и описывают поведение исходного механизма хранения MMAPV1, который не имеет отдельного кэша или поддержки сжатия.
Настройки кэша WiredTiger контролируют только объем памяти, непосредственно используемый механизмом хранения WiredTiger (но не общий объем памяти, используемый mongod). Многие другие вещи могут занимать память в конфигурации MongoDB / WiredTiger, например:
WiredTiger сжимает дисковое хранилище, но данные в памяти не сжимаются.
WiredTiger по умолчанию не синхронизирует данные при каждом коммите , поэтому файлы журнала также находятся в оперативной памяти, что сказывается на памяти. Также упоминается, что для эффективного использования операций ввода-вывода WiredTiger объединяет запросы ввода-вывода (ошибки кэширования), что также требует некоторой оперативной памяти (на самом деле грязные страницы (страницы, которые были изменены / обновлены) имеют список обновлений). на них хранятся в параллельном SkipList ).
WiredTiger хранит несколько версий записей в своем кэше (управление одновременной версией нескольких версий, операции чтения обращаются к последней подтвержденной версии перед их работой).
WiredTiger Сохраняет контрольные суммы данных в кеше.
Сам MongoDB использует память для обработки открытых соединений, агрегатов, серверного кода и т . Д.
Учитывая эти факты, полагаться на show dbs; это не было технически правильно, так как он показывает только сжатый размер наборов данных.
Следующие команды могут использоваться для получения полного размера набора данных.
Эти результаты следующие:
Таким образом, кажется, что фактический размер набора данных + его индексы занимают около 68 ГБ этой памяти.
Учитывая все это, я предполагаю, что использование памяти теперь вполне ожидаемое, хорошая часть в том, что вполне нормально ограничить размер кэша WiredTiger, поскольку он довольно эффективно обрабатывает операции ввода-вывода (как описано выше).
Также остается проблема OOM, чтобы преодолеть эту проблему, так как у нас не было достаточно ресурсов, чтобы убрать mongodb, мы понизили oom_score_adj, чтобы OOM не убивал важные процессы на данный момент (то есть мы сказали OOM не убивать наши желаемые процессы ).
У нас похожая проблема. MongoDB продолжает поглощать оперативную память. Схожие пропорции. Было ли oom_score_adj решение лучшим, что вам удалось придумать?
@Hartator Что ж, мы сократили cacheSize wiredtiger, приложили больше усилий для управления нашими индексами и политикой индексирования, а затем, наконец, уменьшили oom_score_adj для вещей, о которых мы заботились, и я думаю, все, что можно сделать в любом случае.
Я не думаю, что у вас есть проблема с MongoDB, так как jstell сказал, что MongoDB с WiredTiger будет использовать 50% доступной памяти, поэтому, если вы увеличите объем оперативной памяти вашего сервера, потребуется больше памяти.
Поэтому размер индексов DB + превышает размер, имейте в виду, что WiredTiger сжимает базу данных на диске, а также использует журналы моментальных снимков для записи изменений документа. Таким образом, реальный размер WiredTiger - это размер с использованием show dbs * compress_ration + size журналов снимков. Так что почти невозможно узнать точный ожидаемый размер.
Имейте также в виду , что такие инструменты , как top , ps , htop не проявляла память действительно , используемый приложением, refere к этому SOW вопрос для деталей: /programming/131303/how-to-measure-actual-memory -usage-оф-ан-приложения или-процесс
Теперь вернемся к вашей проблеме. У вас есть другие инструменты, работающие на том же хосте, и OOM убивает их. Я не знаком с Linux OOM, но вы уверены, что он убивает тех из-за MongoDB или . просто из-за них (возможно, это убивает Postgres, потому что Postgres занимал слишком много памяти).
В любом случае, если у вас есть большая база данных Mongo, лучше не устанавливать ее на хосте, совместно используемом с другими базами данных, иначе у вас возникнет много трудностей, если возникнет проблема, подобная той, которую вы описали здесь, кто действительно вызывает проблему на хосте.
Команда db.serverStatus() ( docs ) может предоставить обзор использования памяти, а именно:
db.stats() может показать общий размер всех индексов, но мы также можем получить подробную информацию для одной коллекции, используя db.myCollection.stats()
Например, эта команда будет сравнивать размеры индексов для каждой коллекции :
Теперь мы можем взглянуть на детали этой огромной коллекции, чтобы увидеть, какие из ее индексов являются самыми дорогостоящими:
Это может дать нам лучшее представление о том, где возможна экономия.
(В этом случае у нас createTime был довольно большой индекс - одна запись на документ - и мы решили, что можем жить без него.)
Достаточно ли иметь весь индекс в памяти / оперативной памяти или mongodb даже пытается выделить как можно больше оперативной памяти для хранения даже данных для быстрого чтения?
Я хотел бы запустить mongodb + другие приложения, и похоже, что mongodb - единственное, которое не позволяет мне определять диапазон оперативной памяти, скажем, "max_memory_allocated_or_reserved = 8GB".
Если нет никакого способа сделать это, я должен объяснить oom-killer, что mongod - это «плохой» процесс, который, на мой взгляд, не является лучшей практикой .
Настоящая причина, по которой вы не можете делать, как просите (ограничить память), заключается в том, что MongoDB не управляет памятью, которую использует напрямую, - это позволяет ОС делать это. MongoDB просто память отображает все свои данные, а затем выдает страницу ОС в память и из памяти по мере необходимости. В результате прямого управления используемым количеством невозможно, пока MongoDB не реализует это совершенно по-другому, или ОС не позволяет это (в Linux это невозможно через 2,4 дня).
Единственный способ по-настоящему разделить ресурсы в настоящее время - это использовать решение для виртуализации и изолировать MongoDB в своей собственной виртуальной машине. Да, это связано с накладными расходами (хотя гипервизоры стали намного лучше), но на данный момент это цена, которую нужно заплатить за этот уровень контроля ресурсов.
С точки зрения OOM Killer, даже при отсутствии других процессов на хосте, если ваш набор данных и индексы в целом превышают доступную память, MongoDB может столкнуться с проблемами OOM Killer. Это происходит из-за того, что данные выгружаются из памяти - если нет никакого давления памяти (больше ничего не требуется резидентной памяти), и вы продолжаете добавлять / касаться новых данных и индексов, то в конечном итоге они будут расти, чтобы использовать всю доступную оперативную память. Отсюда рекомендация всегда настраивать некоторый своп при запуске MongoDB:
Конечно, данные LRU будут сначала выгружены, другие процессы также могут занимать res mem, но концепция все еще применима, если вы не загрузите свой набор данных в память, а затем он останется статичным. Лучшее, что вы можете сделать, если вы беспокоитесь, это вставить его в MMS и отслеживать его использование с течением времени:
Обновление: август 2015
С тех пор, как я написал этот ответ, ситуация несколько изменилась, и информация немного устарела. Например, в Linux теперь есть cgroups и связанные с ними технологии ( например, контейнеры Docker ), которые достигли такой степени зрелости, что позволяют вам лучше изолировать и ограничивать ресурсы ( включая память ), потребляемые любым процессом в производственной среде, даже той, которая использует отображение памяти как MongoDB.
Кроме того, с появлением новых механизмов хранения помимо MMAP, таких как WiredTiger, в MongoDB 3.0+ вы можете использовать встроенные функции для ограничения размера кэша для MongoDB. Следовательно, требования к ОЗУ теперь действительно зависят от того, как вы решите сконфигурировать MongoDB, в какой среде вы ее запускаете и какой механизм хранения вы выбираете.
относительно WiredTiger: « storage.wiredTiger.engineConfig.cacheSizeGB ограничивает только размер кэша WiredTiger, а не общий объем памяти, используемый mongod. Кэш WiredTiger является только одним компонентом оперативной памяти, используемой MongoDB. MongoDB также автоматически использует все освободить память на машине через кеш файловой системы . »
верно, но то же самое можно сказать и о любом приложении, которое выгружает данные с диска, кэш FS больше не является основным методом кеширования данных, как это было раньше с отображенными в память файлами в механизме хранения MMAP
MongoDB будет использовать доступную свободную память для кэширования и при необходимости подкачки на диск, чтобы выделить память для других приложений на том же сервере. Для достижения наилучшей производительности вам понадобится достаточно оперативной памяти для хранения ваших индексов и часто используемых данных («рабочего набора») в памяти.
Что-то изменилось за последние годы о MongoDB.
Должен ли мой рабочий набор соответствовать размеру ОЗУ?
Нет.
Как рассчитать, сколько оперативной памяти мне нужно для моего приложения?
В WiredTiger MongoDB использует как внутренний кеш WiredTiger, так и кеш файловой системы.
Изменено в версии 3.2: Начиная с MongoDB 3.2, внутренний кеш WiredTiger по умолчанию будет использовать большее из следующих значений:
60% оперативной памяти минус 1 ГБ или 1 ГБ.
Прямой разговор об использовании vuex в проекте vue-cli
Что такое Vuex? монтаж Напишите код: Добавьте этот файл в main.js Вот 4 основных концепции. State Откройте index.js под файлом магазина Подготовьте два компонента (назовите как хотите) Header.vue Foot.
Система новостей Burdock (1) Что такое генератор классов сущностей?
предисловие В настоящее время автор изучает систему выпусков новостей о лопухе с невероятной скоростью. Сегодня я наконец-то решил, что в этой колонке написано что-то новое, чего я не понимаю при разр.
Читайте также: