node.js - 为我的 Node 应用程序选择正确的数据库

Question

我是 node js 的新手，我需要有关为我的 node 应用程序选择数据库的建议。

比如说，我的列表中有很多游戏(以千计)。数组应该看起来像这样:

{
    "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 */ ...

}

现在，我将通过应用程序名称查询游戏。我想将这个数组结构存储到 Node 的数据库中。我应该去哪一个？哪一个易于管理/更新且更快？我应该使用 NoSQL 数据库吗？

Answer 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——————————

我希望这对您有所帮助，也能为您提供更多信息。据我所知，mongo 不保证在您使用时不会丢失数据，它们只保证快速数据流。