2016-06-29 2 views
1

Я новичок в узле js & Мне нужны предложения по выбору базы данных для моего приложения-узла.Выбор правильной базы данных для моего узла app

Скажите, у меня есть количество игр (в тысячах) в моем списке. Массив должен выглядеть примерно так:

{ 
    "Football": 
     { 
      "John": [{ 
         "age": "1", 
         "weight": "2", 
         "height": "3", 
        }], 
      "Smith": [{ 
         "age": "11", 
         "weight": "22", 
         "height": "33", 
        }], 
      ... 
     }, 
    "Golf": 
     { 
      "Ricky": [{ 
         "age": "4", 
         "weight": "5", 
         "height": "6", 
        }], 
      "Jonathan": [{ 
         "age": "44", 
         "weight": "55", 
         "height": "66", 
        }], 
      ... 
     }, 

     ... /* Thousand more to go */ ... 

} 

Теперь, используя приложение, я буду запрашивать игры по их имени. Я хочу сохранить эту структуру массива в базе данных для узла. На какой я должен пойти? Какой из них проще в управлении/обновлении & быстрее? Должен ли я использовать базу данных NoSQL?

+0

I suggesst DynamoDB АМС лучшего. –

ответ

1
So i made a little research here it is 
Mongo vs MySql 
——————————o—————————— 
References: 
—> ‘https://www.mongodb.com/compare/mongodb-mysql' 
—> ‘https://www.upguard.com/articles/mysql-vs-mongodb’ 
—> ‘https://www.techopedia.com/6/28832/enterprise/databases/introduction-to-databases/6’ 
—> ‘https://docs.mongodb.com/manual/reference/sql-comparison/’ 
——————————o—————————— 
MySql 
√ MySQL is a popular open-source relational database management system (RDBMS) that is developed, distributed and supported by Oracle Corporation. Like other relational systems, MySQL stores data in tables and uses structured query language (SQL) for database access. In MySQL, you pre-define your database schema based on your requirements and set up rules to govern the relationships between fields in your tables. In MySQL, related information may be stored in separate tables, but associated through the use of joins. In this way, data duplication is minimized. 
√ The basic MySQL system ships with no GUI tools, only a set of CLI’s. There is an official set of front-end tools called MySQL Workbench, freely available from Oracle. MySQL runs on all major operating systems 
—>When MySql is a Better Choice: 
√ Applications that require complex, multi-row transactions (e.g., a double-entry bookkeeping system) would be good example. A concrete example would be the booking engine behind a travel reservation system, which also typically involves complex transactions. 
√ MySQL is mostly used in to store data for web applications but that’s not to say MySQL cannot support large enterprise databases 
——————————o—————————— 
MongoDB vs MySql 
—> Terminology and Concepts: 
Ø MySql: Table, Row, Column, Joins 
Ø MongoDB: Collection, Document, Field, Embedded documents and Linking 
—> Features: 
Ø MySql: Typed Data, Field Updates, Complex Transactions, Auditing 
Ø MongoDB: Rich Data Model, Dynamic Scheme, Typed Data, Data Locality, Field Updates, *Easy For Programmers*, Auditing, Auto Sharing. 
——————————o—————————— 
MongoDB 
√ MongoDB is a well-known open source non-relational database. It employs the concept of key-value pairs, here called a document store. In MongoDB document stores are created and stored as BSON files, which are really a modified version of JSON files. 
√ Mongo offers very good performance for situations containing very high write loads, but where data integrity isn’t a pressing concern; a good example are the comments sections of large, busy websites like Craigslist or The New York Times – by the way, these aren’t theoretical by the way: both of these use MongoDB. 
√ One major limitation of MongoDB is that unlike the relational MySQL, it does not offer an easy way to join tables. It has an inelegant solution to this: multi-dimensional data types in which you can embed one document store inside another. So for instance you can embed the customer account document consisting of the {“Customer_account_type: Current”, “Customer_balance: $28,400”} document into the customer data document {“Customer name: Andrew Jones, “Customer_gender: M”} and in this way retrieve the data about both the customer and his bank balance. As mentioned, it’s inelegant and awkward but it works. 
—> Common Use Cases: 
√ MongoDB is a general purpose database that is used for a variety of use cases. The most common use cases for MongoDB include Single View, *Internet of Things*, *Mobile*, *Real Time Analytics*, Personalization, Catalog, and Content Management 
——————————o—————————— 
Relational Data Bases 
√ Relational databases are excellent for representing and working with sets of data, similar to finding the region covered by intersection points in a Venn diagram. For instance, in a commercial bank’s application, it is simplicity itself to create a SQL query to extract, say, the names and contacts of all female customers, with a current-account balance over $100,000, who have taken out a loan in your bank within the last 2 years. SQL can easily allow you to get that accurate using the famous SELECT statement. The tight rules governing relational database structure mean that it is easy to ensure data integrity and security. 
√ However, what SQL and relational databases are not good at is scaling. Because of the necessary table and database structure in relational databases, they really only scale well vertically within a single server - by increasing memory and CPU, using faster disks, etc. But they don’t scale well horizontally by adding more servers to share the load, i.e. distributed computing. This is where the relational models own strengths turn into weaknesses. 
√ They have three main advantages: 
    1. A simple way of representing data/ business models 
    2. An easy-to-use language to retrieve and query that data (SQL) 
    3. Bulletproof data integrity and security built right into the database without having to rely on application rules and logic. 
√ Are like trains: Better for moving large quantities of goods 
——————————o—————————— 
Non-Relational Data Bases 
√ One of their defining characteristics is that they are able to take scale very well across several servers and reap the advantages of distributed computing. With the advent of fast Internet connections, these servers may be in sync even over widely dispersed geographical locations (Google!). One way of achieving this is by storing data in key-value pairs, rather than the traditional table. A key-value pair is a combination of a data item and its related value. 
√in NoSQL databases, the data field and the value for that field are stored together as one record. This makes data retrieval much faster and enables , but also introduces problems with data integrity. A relational table, on the other hand, would store the same customer data as a set of distinct tables, one containing the customer bio-data (name, date of birth, gender, social security number and so on), another containing customer balances (account type, balance) and so on. 
√ Are like cars: Better for smaller quantities of goods 
——————————o—————————— 

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

0

СУБД (SQL DB) против NoSQL

SQL DB

  • Поддерживает отношения между данными
  • Фиксированный или предопределенные схемы
  • Данные хранятся в строках и столбцах
  • Вертикально масштабируемый (будет ограничен на оборудовании, скажем, вы не можете p при добавлении RAM в серверную машину, у машины есть свой лимит того, сколько ОЗУ можно увеличить)
  • Хранение и получение сравнительно медленнее, когда данные огромны.

NoSQL БД - Никакого отношения не поддерживается между данными - Динамическая схема - Данные сохраняются в виде документа, графика, значение ключа и так далее (https://en.wikipedia.org/wiki/NoSQL) - Горизонтально масштабируемая который просто может быть осуществляется путем добавления дополнительных серверов - Сохранение и извлечение быстрее

Какой легко управлять/обновления & быстрее

Если вы хотите быстрее управлять или обновлять, NoSQL будет наилучшим образом подходит для вашей схемы и объема ваших данных.

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

Пример данных после реструктуризации

{ "id": 1, 
    "name": "John", 
    "age": "1", 
    "weight": "2", 
    "height": "3", 
    "games": [{ "Football"}] 
} 
Смежные вопросы