Работа с огромной базой JSON (>50 ГБ)
Здравствуйте, возникла необходимость работы с загруженной базой от стороннего ресурса, база была скачана полностью, чтобы не тянуть данные через API.
Задача в принципе одна, нужно с ней работать офлайн, в принципе даже через Access или Excel можно.
Я предполагаю как, эту базу переконвертировать в CSV и запихнуть в MySQL и дальше уже работать там, но большой размер базы вызывает большие трудности в работе с ней.
Есть ли какие-то альтернативы?
korsakik
16.12.18 05:15:05 MSK
← 1 2 →
50Гб не должно вызывать проблем после импорта в мускуль/постгресс/whatever.
Уточни формат данных и что значит «работать», иначе не понятно что тебе посоветовать.
kardapoltsev ★★★★
( 16.12.18 05:49:30 MSK )
Если это .json файлы в количестве 50 Гигов — то загружать есть смысл в Mongo/ArangoDB/CouchDB, а не в MySQL.
menangen ★★★★★
( 16.12.18 08:31:15 MSK )
anonymous
( 16.12.18 11:14:23 MSK )
Непонятно, в чём именно проблемы. 50 ГБ это не огромные размеры, это крошечные размеры.
Legioner ★★★★★
( 16.12.18 11:53:11 MSK )
Ответ на: комментарий от Legioner 16.12.18 11:53:11 MSK
Видимо проблема в том что тс не может найти потоковый парсер который не будет пытатьтся сразу проглотить весь документ.
redixin ★★★★
( 16.12.18 12:10:39 MSK )
Есть предположение, что после заливки твои 50гигов ужмуться, да и без этого не такие уж великие размеры. Даже мускуль прожует.
ya-betmen ★★★★★
( 16.12.18 12:10:58 MSK )
Ответ на: комментарий от redixin 16.12.18 12:10:39 MSK
Не факт. Скорее всего у него миллионы мелких JSON-ов, а не один огромный. Даже если так, для какого это языка нет потокового парсера? Даже если так, JSON это примитивный формат, парсер для которого пишется на коленке за час.
Legioner ★★★★★
( 16.12.18 12:44:40 MSK )
Я предполагаю как, эту базу переконвертировать в CSV и запихнуть в MySQL
Направление мысли здравое, но лучше таки не через CSV, он узким местом будет.
Был бы XML, я б тебе посоветовал написать SAX-парсер. Сейчас бегло погуглил — для JSON в подобных случаях люди тоже велосипедят аналог SAX.
hobbit ★★★★★
( 16.12.18 12:53:03 MSK )
Ответ на: комментарий от menangen 16.12.18 08:31:15 MSK
Если это .json файлы в количестве 50 Гигов — то загружать есть смысл в Mongo/ArangoDB/CouchDB, а не в MySQL.
И зачем ты для этой задачи предлагаешь всякую NoSQLщину? 50 Гб — это семечки для нормальной реляционной СУБД, того же PostgreSQL, например (кстати, возможно, что и для MySQL тоже, просто не пробовал).
hobbit ★★★★★
( 16.12.18 12:54:56 MSK )
Ответ на: комментарий от Legioner 16.12.18 11:53:11 MSK
Для JSON, ага. Некоторых упоротых товарищей хлебом не корми, дай только херни сказануть.
WitcherGeralt ★★
( 16.12.18 17:55:27 MSK )
А чего именно тебе нужно делать с бащой и как? Clickhouse может импортировать напрямую из json и для него такой объём данных — ничто, минимум пердолинга предстоит. Ну илм можешь взять питонический ijson, например, и написать скрипт в несколько строк, который в stdout будет плевать csv для импорта в любую другуб бд.
WitcherGeralt ★★
( 16.12.18 18:06:32 MSK )
mos ★★☆☆☆
( 16.12.18 18:25:18 MSK )
Ответ на: комментарий от Legioner 16.12.18 11:53:11 MSK
ну если у сервака 512 гигов, то да
tz4678 ★★
( 17.12.18 13:16:00 MSK )
Ответ на: комментарий от tz4678 17.12.18 13:16:00 MSK
Да даже если 256 мегов, тоже нормально.
Legioner ★★★★★
( 17.12.18 16:32:30 MSK )
Выше правильно написали, что конвертировать в csv перед записью в СУБД не нужно.
Я бы советовал данные запихнуть в mysql, затем нормализовать базу данных.
dicos ★★
( 11.01.19 12:15:11 MSK )
база была скачана полностью, чтобы не тянуть данные через API.
но большой размер базы вызывает большие трудности в работе с ней. Есть ли какие-то альтернативы?
Тянуть данные через API ?
router ★★★★★
( 11.01.19 12:16:43 MSK )
Я бы все-таки подумал бы либо об документоориентированной бд (монга) либо о встроенных механизмах хранения json в других базах, напр., в постгрессе.
Если это данные стороннего сервиса, без строгих гарантий на соблюдения формата + если стоит задача не единоразово проделать эту операцию, а постоянно обновлять базу, то будет постоянный геммор подгонять схему под изменения данных. Учитывая, что сторонние ребята хранят все в json, я думаю, они не будут особо париться с их содержимым.
Deleted
( 11.01.19 14:09:51 MSK )
Может так проще.
comma ★
( 11.01.19 14:43:48 MSK )
Ответ на: комментарий от hobbit 16.12.18 12:54:56 MSK
И зачем ты для этой задачи предлагаешь всякую NoSQLщину?
Потому что json древовидный.
adn ★★★★
( 11.01.19 15:07:11 MSK )
Ответ на: комментарий от WitcherGeralt 16.12.18 18:06:32 MSK
Ну илм можешь взять питонический ijson, например, и написать скрипт в несколько строк, который в stdout будет плевать csv для импорта в любую другуб бд.
Чувак, ты не в теме. Ты не разложишь древовидный json в плоский CSV (или любую другую таблицу)
adn ★★★★
( 11.01.19 15:09:26 MSK )
Последнее исправление: adn 11.01.19 15:16:51 MSK (всего исправлений: 1)
Ответ на: комментарий от comma 11.01.19 14:43:48 MSK
Неа. Не проще. В MySQL и postgres есть только поля формата json. В итоге ты получишь примерно то же самое, что получил бы храня это в текстовом файле. Mongo — отличный выбор для этого. Это ее use case.
adn ★★★★
( 11.01.19 15:16:06 MSK )
Ответ на: комментарий от adn 11.01.19 15:09:26 MSK
Я-то как раз в теме. А ты мало того, что выдумал кейс о котором нет речи в топике, так ещё глупость сморозил.
Ничто не мешает его разложить на несколько таблиц, если объекты имеют разную структуру, либо в одну, если структура вложенных объектов идентична родителю. Просто генеришь айдишники и добавляешь поля для внешних ключей / ссылок на другие записи той же таблицы.
Проблема возникает только если тебе нужно извлекать это из таблиц обратно в json. В зависимости от субд масштаб проблемы разный, но это всегда решаемо, хоть и не всегда адекватно. В самом худшем случае придётся собирать его вне таблицы, отправляя по запросу на каждый объект, а в лучшем, собрать можно прямо в хранимой процедуре.
WitcherGeralt ★★
( 11.01.19 16:05:33 MSK )
Ответ на: комментарий от WitcherGeralt 11.01.19 16:05:33 MSK
Ничто не мешает его разложить на несколько таблиц, если объекты имеют разную структуру, либо в одну, если структура вложенных объектов идентична родителю. Просто генеришь айдишники и добавляешь поля для внешних ключей / ссылок на другие записи той же таблицы.
Разложить то можно, а вот что-то делать с этим проблематично.
Проблема возникает только если тебе нужно извлекать это из таблиц обратно в json.
Ты и сам это тут же подтверждаешь. Это будут просто как-то уложенные в таблицы данные.
Зачем копать яму молотком, когда существуют лопаты?
adn ★★★★
( 11.01.19 16:54:33 MSK )
Ответ на: комментарий от adn 11.01.19 15:16:06 MSK
с того момента, как в постгрес завезли jsonb, нужность монги под большим сомнением, особенно после того, как утихли визги про noSQL и в свежие монги начали пихать ACID под своим, кислотным соусом.
постгрес развивается просто дичайшими темпами, но уже 3 года назад нагибал nosql в «её» use case
SevikL ★★★★★
( 11.01.19 17:03:28 MSK )
Ответ на: комментарий от adn 11.01.19 16:54:33 MSK
а вот что-то делать с этим проблематично
Зависит от задачи. Ты заведомо предположил такую, в которой от укладывания в таблицы одни проблемы, но найдётся и тысяча кейсов, где всё ровно наоборот. У ТС мб в json вообще что-то типа лога.
WitcherGeralt ★★
( 11.01.19 17:06:44 MSK )
Ответ на: комментарий от SevikL 11.01.19 17:03:28 MSK
нужность монги под большим сомнением, особенно после того, как утихли визги про noSQL
Меня очень веселит, что спорят со мной люди, которые вообще не представляют что такое noSQL и зачем он нужен. И так же, похоже не знают как выглядит json. И я не знаю как postgres кого «натягивает», но хотел бы посмотреть на insert, который добавит hashtag в статью.
Сравнение SQL и NoSQL: как выбрать систему хранения данных
Согласно рейтингу DB-Engines, в топе самых популярных СУБД четыре реляционных (SQL) и одна нереляционная (NoSQL). Реляционные базы данных занимают львиную долю рынка и наиболее известны. Однако в ряде случаев лучше выбрать NoSQL-решения различного типа.
Мы подготовили небольшой гайд по типам баз данных, чтобы вы могли принять верное решение.
Что такое реляционные и нереляционные базы данных
Реляционная база данных (SQL) — база, где данные хранятся в формате таблиц, они строго структурированы и связаны друг с другом. В таблице есть строки и столбцы, каждая строка представляет отдельную запись, а столбец — поле с назначенным ей типом данных. В каждой ячейке информация записана по шаблону.
Нереляционная база данных (NoSQL) — хранит данные без четких связей друг с другом и четкой структуры. Вместо структурированных таблиц внутри базы находится множество разнородных документов, в том числе изображения, видео и даже публикации в социальных сетях. В отличие от реляционных БД, NoSQL базы данных не поддерживают запросы SQL.
Реляционные базы данных, или базы данных SQL
Особенности. Основная особенность — надежность и неизменяемость данных, низкий риск потери информации. При обновлении данных их целостность гарантирована, они заменяются в одной таблице.
Реляционные базы данных, в отличие от нереляционных, соответствуют ACID — это требования к транзакционным системам. Соответствие им гарантирует сохранность данных и предсказуемость работы базы данных:
- Atomicity, или атомарность — ни одна транзакция не будет зафиксирована в системе частично.
- Consistency, или непротиворечивость — фиксируются только допустимые результаты транзакций.
- Isolation, или изолированность — на результат транзакции не влияют транзакции, проходящие параллельно ей.
- Durability, или долговечность — изменения в базе данных сохраняются несмотря на сбои или действия пользователей.
При работе с такими СУБД надо учитывать, что любые изменения в объектах нужно отражать в структуре таблиц, физическая структура данных не соответствует объектной модели приложения.
Реляционные БД идеальны для работы со структурированными данными, структура которых не подвержена частым изменениям.
Так выглядит хранение данных в реляционной базе, по сути, это просто таблица:
| Клиент | Средний чек | Число покупок за период |
| 1 | 1000 | 10 |
| 2 | 1500 | 5 |
| 3 | 800 | 6 |
Масштабируемость. Вертикальная, то есть при росте нагрузки растет производительность сервера. Если в базу поступает большой объем данных, рано или поздно наступит порог вертикального масштабирования — сервер не сможет далее увеличивать производительность. Тогда понадобится горизонтальное масштабирование — параллельная обработка данных в кластере серверов.
В больших распределенных системах это может привести к тому, что общая производительность системы упадет, так как нужно поддерживать согласованность данных в нескольких узлах. Это не значит, что СУБД на SQL не подходят для больших проектов — они поддерживают кластеризацию, просто нужно приложить усилия, чтобы настроить систему. Либо использовать базы данных в облаке — там можно получить уже настроенные и надежно работающие кластеры в несколько кликов.
Самые известные SQL-базы данных
MySQL — одна из самых популярных open source реляционных баз данных. Подходит небольшим и средним проектам, которым нужен недорогой и надежный инструмент работы с данными. Поддерживает множество типов таблиц, есть огромное количество плагинов и расширений, облегчающих работу с системой.
Отличается простой установкой, может быть интегрирована с другими СУБД, также интеграция с MySQL есть в любой CMS, фреймворке, языке программирования. Среди минусов — не все задачи выполняет автоматически, если что-то нужное не включено в функционал, придется потратить время на доработку, нет встроенной поддержки OLAP.
MySQL доступна как облачный сервис — в облаке не нужно тратить много времени на развертывание и конфигурацию СУБД. MySQL server стоит выбрать на старте бизнеса, чтобы тестировать гипотезы с минимальными затратами или для небольших проектов как транзакционную базу данных общего назначения.
PostgreSQL — вторая по популярности open source SQL СУБД. У нее много встроенных функций и дополнений, в том числе для масштабирования в кластер и шардинга таблиц. Подходит, если важна сохранность данных, предполагается их сложная структура. Позволяет работать со структурированными данными, но поддерживает JSON/BSON, что дает некоторую гибкость в схеме данных.
Отличается стабильностью, ее практически невозможно вывести из строя или что-то сломать в таблицах.
Из минусов — сложность конфигурации требует от пользователей некоторого опыта. Также скорость работы может падать во время проведения пакетных операций или при запросах на чтение.
PostgreSQL также можно развернуть в облаке — в отличие от MySQL, она подходит для крупных и масштабных проектов. Кроме того, ее стоит выбрать, если недопустимы ошибки в данных или есть особые требования к базе данных, например поддержка геоданных. Различные расширения PostgreSQL позволяют реализовать многие специализированные запросы.
Подробно о разнице между PostgreSQL и MySQL мы писали в отдельной статье.
Нереляционные базы данных, или базы данных NoSQL
Особенности. В отличие от реляционных, в нереляционных базах данных схема данных является динамической и может меняться в любой момент времени. К данным сложнее получить доступ, то есть найти внутри базы что-то нужное — с таблицей это просто, достаточно знать координаты ячейки. Зато такие СУБД отличаются производительностью и скоростью. Физические объекты в NoSQL обычно можно хранить прямо в том виде, в котором с ними потом работает приложение.
Базы данных NoSQL подходят для хранения больших объемов неструктурированной информации, а также хороши для быстрой разработки и тестирования гипотез.
В них можно хранить данные любого типа и добавлять новые в процессе работы.
Масштабируемость. NoSQL базы имеют распределенную архитектуру, поэтому хорошо масштабируются горизонтально и отличаются высокой производительностью. Технологии NoSQL могут автоматически распределять данные по разным серверам. Это повышает скорость чтения данных в распределенной среде.
Четыре вида нереляционных баз данных
Документоориентированные базы данных — данные хранятся в коллекциях документов, обычно с использованием форматов JSON, XML или BSON. Одна запись может содержать столько данных, сколько нужно, в любом типе данных (или типах) — ограничений нет. Внутри одного документа есть внутренняя структура, однако, она может отличаться от одного документа к другому. Также документы можно вкладывать друг в друга.
То есть вместо столбцов и строк мы описываем все данные в одном документе. Если нам нужно было бы добавить новые данные в таблицу реляционной базы данных, пришлось бы изменять ее схему данных. В случае с документами нужно только добавить в них дополнительные пары ключ-значение.
Пример такой базы данных: MongoDB.
Вот так будет выглядеть хранение данных в отдельных документах вместо таблицы со столбцами и строками:
Какая база подойдет для быстрых операций с JSON?
Мне нужна база для быстрых операций с json. Суть такова. Есть массив объектов. Каждую секунду в этот массив добавляется объект. Всё это надо хранить в json (Временные метки хранить не надо). Подойдет ли MYSQL? Или может для JSON что-то получше посоветуете?
- Вопрос задан более трёх лет назад
- 563 просмотра
Комментировать
Решения вопроса 5
Знаю больше чем это необходимо
для json лучше всего подходит Mongo.
Но я бы подумал над тем что за данные у вас — если вы просто добавляете и добавляете +- одинаковые записи и по ним потом надо поиск например делать — то лучше подойдет elasticsearch. А если вы что-то еще делаете — то лучше подойдет что-то другое.
Главное не формат данных для хранения а операции над ними. Хранить то и в текстовом файле можно.
Ответ написан более трёх лет назад
Нравится 2 1 комментарий
semki096 @semki096 Автор вопроса
у меня стоит mysql. Но есть данные которые будут хранится как массив и браться целиком без всяких выборок. Подумал что было бы неплохо их вынести.
xmoonlight @xmoonlight
https://sitecoder.blogspot.com
JSON — это формат структуры для обмена данными.
А база — это хранилище данных структуры.
Поэтому, любая подойдёт.
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
coderisimo @coderisimo
MongoDB. JSON-подобные документы это формат в котором она хранит свои данные.
Формат данных в MongoDB
Одним из популярных стандартов обмена данными и их хранения является JSON (JavaScript Object Notation). JSON эффективно описывает сложные по структуре данные. Способ хранения данных в MongoDB в этом плане похож на JSON, хотя формально JSON не используется. Для хранения в MongoDB применяется формат, который называется BSON (БиСон) или сокращение от binary JSON.
BSON позволяет работать с данными быстрее: быстрее выполняется поиск и обработка.
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
при чем тут json? подойдет любая база которая умеет хранить строки, если одна база не будет успевать то нужна распределенная, балансирующий узел, кластеры, вот это все
и если надо быстро складывать то это скорее что-то из NoSQL
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
mayton2019 @mayton2019
Bigdata Engineer
Баз подойдет много. Mongo подходит. PostgreSQL тоже подходит с их новым типом JSONB и текстовым индексом. На одном из семинаром главный Постгресщик Бартунов хвастался что на тестах производительности этот тип данных обгоняет Mongo. Хотя ХЗ как это проверить на кастомных проектах.
Берите одно из двух исходя из стоимости владения.
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
Ответы на вопрос 0
Ваш ответ на вопрос
Войдите, чтобы написать ответ
- WordPress
- +1 ещё
Как устранить ошибки в БД с таблицей ActionScheduler?
- 1 подписчик
- 26 окт.
- 24 просмотра
В чем разница между MongoDB и MySQL?
MongoDB и MySQL – это две системы управления базами данных, которые можно использовать для хранения данных и управления ими. MySQL – это реляционная база данных, в которой данные хранятся в структурированном табличном формате. В отличие от нее, MongoDB хранит данные в виде документов JSON в более гибком формате. Оба типа баз данных обеспечивают эффективность и масштабируемость, но наилучшие показатели их работы соответствуют различным вариантам использования.
В чем сходство между MongoDB и MySQL?
И MySQL, и MongoDB являются системами управления базами данных. Они хранят данные и имеют встроенный пользовательский интерфейс и язык запросов, что позволяет добавлять, редактировать, изменять и анализировать данные.
Лицензии с открытым исходным кодом
MySQL и ранние версии MongoDB имеют лицензии с открытым исходным кодом. Версии с открытым исходным кодом можно скачать бесплатно. Затем вы можете изменить код в зависимости от того, что вам нужно с ним делать.
На MySQL распространяется лицензия General Public License GNU. Все версии MongoDB, выпущенные до 16 октября 2018 г., доступны под лицензией GNU Affero General Public License.
Поддержка индексирования
MySQL и MongoDB используют индексацию для повышения скорости и производительности запросов. Индексы – это структуры баз данных, которые связываются с часто используемыми данными. Индекс помогает очень быстро находить и извлекать данные.
Платформы баз данных MySQL и MongoDB используют хэш-индексы, индексы B-дерева и ряд других.
Удобные интерфейсы
MongoDB и MySQL просты в использовании. Они предлагают язык запросов на основе естественного языка для обновления и чтения данных. Они также предлагают графический пользовательский интерфейс (GUI) для более визуального управления данными и их анализа.
Языки программирования
MySQL и MongoDB совместимы с несколькими одинаковыми языками программирования. Можно использовать Java, Python, Node.js, PHP на стороне сервера, Ruby и C# как с MongoDB, так и с MySQL.
Безопасность
MySQL и MongoDB используют аутентификацию, контроль доступа и шифрование для гарантии безопасности своих баз данных. Они используют шифрование TLS/SSL для защиты данных в движении и в местах хранения. Они также позволяют определять различные уровни доступа пользователей.
Документация и поддержка сообщества
MySQL и MongoDB содержат подробную официальную документацию на своих сайтах. Их пособия, руководства и справочники предлагают полные инструкции по установке, настройке и выполнению оперативных задач.
У MongoDB и MySQL также есть активное сообщество разработчиков, в котором вам ответят на вопросы и помогут в устранении неполадок. Оба решения также предлагают корпоративные версии со специальной поддержкой, отвечающей вашим конкретным требованиям.
Ключевые отличия MongoDB и MySQL
MySQL – это система управления реляционными базами данных, а MongoDB – это система баз данных NoSQL. Подробнее об этом можно прочитать в разделах Что такое реляционная база данных? и Что такое NoSQL?.
MySQL использует SQL, с которым большинство разработчиков знакомы. И наоборот, MongoDB использует язык запросов MongoDB (MQL). Хотя между MQL и SQL есть сходство, для изучения языка MQL обычно требуется дополнительные усилия.
Далее мы рассмотрим некоторые другие ключевые отличия.
Модель данных
MySQL – это реляционная система баз данных, которая хранит данные в столбцах, строках и таблицах. Данные хранятся в строках, причем каждый столбец представляет разные типы данных. Затем вы определяете отношения между данными с помощью внешних и первичных ключей. Каждая таблица содержит первичный ключ, который используется для ее идентификации, а внешний ключ создает связь.
MongoDB – это документно-ориентированная база данных, в которой все данные хранятся в виде двоичных документов JSON (BSON). BSON позволяет сериализовать множество форм данных. Использование документов BSON позволяет хранить неструктурированные, полуструктурированные и структурированные данные. Вместо схемы базы данных MongoDB использует гибкий подход, сохраняя документы в коллекциях.
Масштабируемость
В системе баз данных MySQL доступные варианты масштабирования ограничены. Вы можете выбрать один из следующих вариантов:
- Вертикальная масштабируемость за счет добавления дополнительных ресурсов к текущему серверу баз данных
- Репликация чтения путем создания копий базы данных, доступных только для чтения, на других серверах
Репликация чтения ограничена максимум пятью копиями. Реплики также могут отставать от основной копии, что приводит к масштабным проблемам с производительностью. Вертикальная масштабируемость также ограничена используемой инфраструктурой.
Напротив, конструкция MongoDB дает значительное преимущество с точки зрения масштабируемости. Решение имеет две ключевые функции для масштабирования:
- Наборы реплик – группы серверов MongoDB, содержащие идентичные данные
- Сегментирование – разные части данных, распределенные по разным серверам
MongoDB позволяет создавать сегментированные кластеры, поэтому части ваших данных реплицируются на нескольких серверах. Например, если у вас есть большое количество записей о клиентах, вы можете распределить их так, чтобы имена от A до J и имена от K до Z находились в собственном наборе реплик. Таким образом, MongoDB может масштабироваться по горизонтали для оптимизации производительности чтения и записи в нужном масштабе.
Производительность
Решение MySQL предназначено для высокопроизводительных объединений нескольких таблиц, которые надлежащим образом проиндексированы. Однако требуется вставлять данные по строкам, поэтому скорость записи снижается.
Документы MongoDB следуют иерархической модели данных и хранят большую часть данных в одном документе, что снижает необходимость объединения нескольких документов. Соединения поддерживаются операцией $lookup, но они не оптимизированы для повышения производительности. Однако MongoDB предлагает API insertMany() для быстрой вставки данных с приоритетным вниманием производительности записи.
Гибкость
Как система управления реляционными базами данных, MySQL имеет более жесткую структуру, чем MongoDB. MySQL использует фиксированную схему и организует данные в строку и таблицу. Чтобы использовать MySQL, необходимо структурировать данные и поместить их в табличную систему.
Сохраняя данные в виде документов JSON, MongoDB позволяет создавать сложные приложения с различными типами данных. Например, вы можете создавать новые поля, обновляя поля вложенного массива. Можно также использовать конвейер агрегирования – функцию MongoDB, которая позволяет преобразовывать данные, объединяя несколько операций в один рабочий процесс.
Контроль доступа
В MongoDB вы можете управлять доступом на уровне операции, коллекции или базы данных. Для аутентификации пользователей используются сертификаты Kerberos, X.509 и LDAP. Напротив, MySQL позволяет ограничить доступ пользователей на уровне пользователя, базы данных и таблицы. MySQL использует собственную систему аутентификации. Она представляет собой дополнительную уязвимость безопасности при атаках с внедрением SQL-кода, которой позволяет избежать подход MongoDB без схем.
Когда использовать MongoDB и MySQL
Формат хранения данных в MySQL делает его пригодным для хранения данных и аналитической обработки в режиме онлайн. Он совместим с ACID, что означает, что транзакции атомарны, последовательны, изолированы и долговечны. Поэтому решение MySQL полезно при работе со сложными транзакциями, например в электронной коммерции, транзакциях и финансах.
Высокоструктурированные данные и индексация MySQL также подходят для специальных запросов. Специальные запросы обычно выполняются конечными пользователями или аналитиками данных, которым требуется быстрый доступ к данным, недоступным в стандартных отчетах или запросах.
С другой стороны, MongoDB – это база данных NoSQL. Это более удобно при работе с неструктурированными данными в таких случаях использования, как социальные сети, СМИ или Интернет вещей (IoT). Поскольку у MongoDB нет схемы, это хороший выбор для работы с постоянно меняющимися и расширяющимися данными.