Matthew Malthouse
| blog | http://messagepassing.blogspot.com/ |
| old twitter | https://twitter.com/frazerclement |
Frazer Clement
- 9 Followers
- 76 Following
- 78 Posts
Distributed DB developer at MySQL
Ordered indexes in MySQL Ndb Cluster allow efficient [ordered] range scans on primary or secondary keys.
MySQL Ndb Cluster ordered indexes are implemented using the T-tree structure.
T-trees store fixed-size direct row references, avoiding duplication of indexed columns or Primary keys. The index storage cost is independent of the indexed columns' size.
Index partitions are co-partitioned and co-located with table partitions, allowing efficient atomic index maintenance.
Index partitions are built, searched and modified in parallel.
MySQL Ndb Cluster partitions, distributes and scales out tables and indexes, enabling parallel scan, search, filter and join within + between SQL queries.
https://messagepassing.blogspot.com/2011/03/data-distribution-in-mysql-cluster.html
https://mikaelronstrom.blogspot.com/2019/12/ndb-parallel-query-part-1.html
MySQL Ndb Cluster has built in automatic sharding and synchronous replication for HA + scalability.
Ndb HA has some unusual features that make it more efficient and capable than many comparable systems.
Using a stateless arbitrator allows Ndb to offer partition safe HA with just 2 replicas of data, as opposed to the common baseline of 3, saving resources.
Dynamic quorum reconfiguration allows an s shard, r replica system to survive the loss of all but one replica of each shard, as opposed to only surviving the loss of less than half the shard replicas.
sophie@MelissaBearTrix @davidtheeviloverlord @chu To add on to this, quartz has piezo electric qualities. If you strike it, it generates a charge, but if you run a charge through it it bends, completing a circuit. If you take particularly pure quartz, and shape it very precisely, you can make a highly accurate clock circuit, pretty much the most accurate you can get short of using atomic clocks. During WW2 quartz crystals were considered a military secret by the british, as they were used to tune their radios (for radar, etc). Early computers used them extensively, highest I ever saw was 33Mhz.
By writing "quartz" on the watch, they're advertising that it's pretty damn accurate. Compared to pre-quartz based time measurement.
I know modern devices use MEMS devices -- essentially a very tiny tuning fork made on a silicon chip -- for their low frequency clocks (ballpark of 15khz, the standby clock in a phone will use this), I'm not sure how the 100Mhz + signals are made
By writing "quartz" on the watch, they're advertising that it's pretty damn accurate. Compared to pre-quartz based time measurement.
I know modern devices use MEMS devices -- essentially a very tiny tuning fork made on a silicon chip -- for their low frequency clocks (ballpark of 15khz, the standby clock in a phone will use this), I'm not sure how the 100Mhz + signals are made
MySQL Ndb Cluster is GPL open source C++. Everyone can browse the source code, download and build it, modify it, fork the whole project, run it on premises, in the cloud or as a service.
https://github.com/mysql/mysql-server/tree/trunk/storage/ndb
https://dev.mysql.com/doc/refman/8.4/en/source-installation.html
https://dev.mysql.com/downloads/cluster/
#mysql #opensource #ndbcluster #ha #distributedsql
MySQL Ndb Cluster data nodes use a hybrid non blocking thread-per-core architecture for control, scalability and efficiency. This has been a unique advantage for years, rare in DDBMS even now.
http://messagepassing.blogspot.com/2009/09/ndb-software-architecture.html
http://messagepassing.blogspot.com/2009/09/mysql-cluster-development.html
https://mikaelronstrom.blogspot.com/2012/05/history-of-mysql-cluster-architecture.html
#mysql #ha #distributedsql #ndbcluster
http://messagepassing.blogspot.com/2009/09/ndb-software-architecture.html
http://messagepassing.blogspot.com/2009/09/mysql-cluster-development.html
https://mikaelronstrom.blogspot.com/2012/05/history-of-mysql-cluster-architecture.html
#mysql #ha #distributedsql #ndbcluster
MySQL Ndb Cluster Operator simplifies deploying and running MySQL Ndb Cluster on Kubernetes (k8s) environments including managed k8s services in public clouds.
Running MySQL Ndb Cluster on k8s allows resource pooling and sharing with other applications.
MySQL Ndb Cluster has automatic high availability built in. k8s can extend MySQL Ndb Cluster system availability by redeploying pods away from failed worker nodes so that system capacity and redundancy is restored automatically.
https://github.com/mysql/mysql-ndb-operator
https://dev.mysql.com/doc/ndb-operator/8.4/en/introduction.html
MySQL Ndb Cluster is a variant of MySQL and as such supports the MySQL JSON functions, the MySQL JSON type and related functionalities. These mechanisms give the database visibility into stored JSON documents, enabling more efficient storage and processing without tightly constrained schemas.
JSON columns can be stored, retrieved, and queried from MySQL Ndb Cluster in a structured way via SQL or other APIs (MySQL X API, Document store, REST server implementations etc).
JSON data can be selectively indexed using stored generated columns, allowing efficient access or the use of relational constraints.
https://dev.mysql.com/doc/refman/8.4/en/json.html
MySQL Ndb Cluster is often described as an in-memory or main memory database but this is not the whole story.
Tables in Ndb always support :
- Transactions, parallel query, indexes, FKs etc
- Sync replication between nodes in a cluster
- HA with automatic failover and recovery
- Consistent backup
- Async replication via MySQLD
By default Tables in Ndb also have automatic transactional durability via parallel checkpoints and logs, supporting full system recovery from storage. However, this can be disabled for individual tables if desired for highest performance with lowest resource usage. In the event of a full system recovery from storage, these tables will be empty.
By default, all columns of a table are kept in memory at all times, limiting system capacity to full cluster system memory size. However unindexed columns can be marked for disk storage. Values for these columns are stored in pages of a tablespace, and only cached in memory like most other RDBMS. This allows far more data to be stored while retaining predictable fast access via purely in memory indexes.