No cache version.
Caching disabled. Default setting for this page:enabled (code DEF204)If the display is too slow, you can disable the user mode to view the cached version.
Rechercher dans le manuel MySQL
22.1.6.1 Differences Between the NDB and InnoDB Storage Engines
The NDB storage engine is
implemented using a distributed, shared-nothing architecture,
which causes it to behave differently from
InnoDB in a number of ways. For
those unaccustomed to working with
NDB, unexpected behaviors can arise
due to its distributed nature with regard to transactions,
foreign keys, table limits, and other characteristics. These are
shown in the following table:
Table 22.1 Differences between InnoDB and NDB storage engines
| Feature | InnoDB (MySQL 8.0) |
NDB 8.0 |
|---|---|---|
| MySQL Server Version | 8.0 | 8.0 |
InnoDB Version |
InnoDB 8.0.19 |
InnoDB 8.0.19 |
| NDB Cluster Version | N/A | NDB
8.0.19/8.0.19 |
| Storage Limits | 64TB | 128TB |
| Foreign Keys | Yes | Yes |
| Transactions | All standard types | READ COMMITTED |
| MVCC | Yes | No |
| Data Compression | Yes | No (NDB checkpoint and backup files can be compressed) |
| Large Row Support (> 14K) | Supported for VARBINARY,
VARCHAR,
BLOB, and
TEXT columns |
Supported for BLOB and
TEXT columns only (Using
these types to store very large amounts of data can lower
NDB performance) |
| Replication Support | Asynchronous and semisynchronous replication using MySQL Replication; MySQL Group Replication | Automatic synchronous replication within an NDB Cluster; asynchronous replication between NDB Clusters, using MySQL Replication (Semisynchronous replication is not supported) |
| Scaleout for Read Operations | Yes (MySQL Replication) | Yes (Automatic partitioning in NDB Cluster; NDB Cluster Replication) |
| Scaleout for Write Operations | Requires application-level partitioning (sharding) | Yes (Automatic partitioning in NDB Cluster is transparent to applications) |
| High Availability (HA) | Built-in, from InnoDB cluster | Yes (Designed for 99.999% uptime) |
| Node Failure Recovery and Failover | From MySQL Group Replication | Automatic (Key element in NDB architecture) |
| Time for Node Failure Recovery | 30 seconds or longer | Typically < 1 second |
| Real-Time Performance | No | Yes |
| In-Memory Tables | No | Yes (Some data can optionally be stored on disk; both in-memory and disk data storage are durable) |
| NoSQL Access to Storage Engine | Yes | Yes (Multiple APIs, including Memcached, Node.js/JavaScript, Java, JPA, C++, and HTTP/REST) |
| Concurrent and Parallel Writes | Yes | Up to 48 writers, optimized for concurrent writes |
| Conflict Detection and Resolution (Multiple Replication Masters) | Yes (MySQL Group Replication) | Yes |
| Hash Indexes | No | Yes |
| Online Addition of Nodes | Read/write replicas using MySQL Group Replication | Yes (all node types) |
| Online Upgrades | Yes (using replication) | Yes |
| Online Schema Modifications | Yes, as part of MySQL 8.0 | Yes |
Document created the 26/06/2006, last modified the 26/10/2018
Source of the printed document:https://www.gaudry.be/en/mysql-rf-mysql-cluster-ndb-innodb-engines.html
The infobrol is a personal site whose content is my sole responsibility. The text is available under CreativeCommons license (BY-NC-SA). More info on the terms of use and the author.
References
These references and links indicate documents consulted during the writing of this page, or which may provide additional information, but the authors of these sources can not be held responsible for the content of this page.
The author This site is solely responsible for the way in which the various concepts, and the freedoms that are taken with the reference works, are presented here. Remember that you must cross multiple source information to reduce the risk of errors.
