Как профессионалы обрабатывают тысячи, сотни тысяч или потенциально миллионы объектов JSON? Node.js

Question

Как профессионалы работают с тысячами, сотнями тысяч или, возможно, миллионами объектов JSON?

Я недавно завершил небольшое приложение, которое запрашивало дюжину или около того объектов JSON (это были объекты фильмов, сгенерированныеменя). Поскольку я работал с несколькими объектами, мне не нужно было эффективно кодировать, когда я хотел проанализировать и найти в JSON конкретные объекты.

Но если бы я работал над настоящим профессиональным приложением, и оно получило 100 тыс. Объектов JSON, как бы я справился:

1. Хранение всех объектов, чтобы его мог использовать сервер
2. Эффективный поиск определенных объектов

Например, предположим, что эти 100 000 объектов были фильмами, у каждого из которых был тип и список актеров. Могу ли я на самом деле разобрать эти 100 КБ в массив, который я затем перебрал бы, чтобы найти интересующие объекты?

Что если вместо 100 Кбайт у нас есть миллион JSON-объектов фильма во внутренней части? Казалось бы, наличие массива с миллионами записей или просмотр всего миллиона объектов часто было бы действительно неэффективно и могло бы замедлить работу внешнего интерфейса.

Для моего небольшого приложения я просто сохранил все 22 объекта JSON в глобальном массиве. называется "allMovies", и я мог бы сделать простой линейный поиск, чтобы найти то, что мне нужно, но опять же, если у меня есть миллион объектов фильма, я не вижу, как мое приложение (в его текущем состоянии) будет масштабироваться.

Я все еще новичок в этом, но это, по сути, мой вопрос, как эффективно хранить большое количество объектов JSON (которые получил серверная часть) и эффективно их искать. Я ищу руководство по дисциплинам или структурам данных, которые я мог бы реализовать.

Небольшое приложение, которое я сделал, было в файле node.js.

Answer 1

Профессионалы используют базу данных.

Первое, что нужно понять, это то, что вы не работаете с объектами JSON. Вы работаете с данными. Просто JSON - это протокол, по которому вы получаете данные, но это мог быть XML, CSV, ASN.1, Bencoding или Protobuf - формат данных не имеет значения, важен только контент.

Теперь, какой тип базы данных использовать, зависит от данных, скорости, с которой вы получаете данные и что вы хотите делать с данными. Иногда вам придется использовать более одного типа баз данных.

SQL / реляционные базы данных превосходны, когда данные структурированы или имеют сложные отношения. Правильно спроектированная база данных SQL будет разделять разные части данных на разные таблицы, а затем определять отношения между таблицами - например, у вас будет таблица actors для хранения всех актеров, затем таблица movies для хранения всех фильмов, а затем еще один cast таблица, связывающая актеров с фильмами. Это позволяет избежать дублирования данных, особенно когда у вас огромные наборы данных.

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

Базы данных документов, такие как MongoDB и ElasticSearch (Lucene), превосходно справляются с очень быстрой вставкой данных и относительно быстрыми запросами. В простейшем случае база данных просто сохранит ваши данные JSON непосредственно в новый файл (да, большинство баз данных документов основаны на JSON). Однако, как правило, дедупликации данных не происходит, поэтому, если у вас есть база данных фильмов, имена актеров будут дублироваться во всех фильмах, в которых они появляются. С другой стороны, если у вас есть база данных актеров, тогда названия фильмов будутдублируется. Это также иллюстрирует тот факт, что вам необходимо тщательно проектировать структуру баз данных документов и выбирать правильный корневой объект для представления всех данных.

Существуют и другие типы баз данных, но они, как правило, более эзотеричны и используются в оченьконкретные варианты использования, такие как кэширование, ведение журнала и т. д.

Answer 2

Интересный вопрос. На это нет правильного или однозначного ответа. Каждый из нас предоставит ответ, основанный на том, насколько хорошо работает конкретное решение.

Позвольте мне попытаться предоставить решение и набор шагов, которые вы можете предпринять, чтобы завершить решение.

• Ваши данные из вашего описания - это набор объектов кинофильмов, которые будутчасто искал. Большое количество операций чтения.
• И это будет введено один раз и несколько раз обновлено.
• Включает много текстового поиска и сортировки на веб-интерфейсе
• Вы используетеNodeJS и архитектура типа клиент-сервер для вашего приложения, так что это будет включать в себя REST API

Итак, выше приведены некоторые характеристики, которые я мог бы указать, которые мы будем использовать для нашего решения. Поскольку мы видим, что данные, которые у вас есть, должны быть хорошо доступны для поиска и в режиме реального времени, они состоят в основном из данных объекта JSON, которые являются динамическими и могут изменяться. мы можем использовать эластичный поиск, MongoDB или любой другой текстовый поиск, поддерживающий NoSQL DB.

Теперь, когда у нас есть база данных, мы решили приступить к проектированию потока данных.

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

• ссылка 1
• ссылка 2
• ссылка 3

Шаг 1 - Сначала объект кинофильмов должен быть проанализирован и вставлен в базу данных и / или индексы эластичного поиска. Это, я думаю, то, что вы уже сделали в меньшем масштабе, храня объекты в массиве all movies, который может действовать как буфер на стороне клиента. Когда буфер заполнен, вы можете выгрузить массив allMovies в бэкэнд, сделав вызов REST API с помощью XHR или AJAX из вашего приложения.

  // Incoming movies
  var newMovie = {your data from forms, other source, etc}
  allMovies.push(newMovie);
  if(allMovies.length >= 20 )
  {
   //make API call to backend.
   //empty the buffer
    allMovies = [];
  } 
  //else wait for new movie

Шаг 2 : ВклБэкэнд просто хранит данные в вашей базе данных, индексирует наиболее искомые поля. Вот ссылка на 2 базы данных, которые я упомянул.

• индекс mongodb
• индекс эластичного поиска

обратите внимание на то, что индексация эластичного поиска также вставляет данные, где MongoDB имеет 2 шага операций вставки и индексации.

Шаг 3 : это может быть та часть, где вы показываете и позволяетепользователи ищут через вашу базу данных фильмов. Здесь вам нужно будет создать новый API, который предоставит возможность выполнять пользовательский поиск пользователям и, следовательно, веб-интерфейсу приложения. Может быть несколько API или одна конечная точка API, которая принимает несколько параметров, таких как поиск и сортировка.

• Вот как выглядит пример API GET /twitter/_search?q=tag:wow Вот некоторые справочные ресурсы для разработки API, ваш результат может отличаться в зависимости от ваших требований.
• Get Users API
• API поиска для поиска музыкальных треков

* Последний шаг - объединение всего этого для получения результатов для вашегоприложение без шва. Я попытаюсь проиллюстрировать этот поток на простой диаграмме.