Our great sponsors
-
MySQL
MySQL Server, the world's most popular open source database, and MySQL Cluster, a real-time, open source transactional database.
In the early 2000s, this was a very common "scaling" solution for MySQL databases for example, where once you ran into more write capacity than what one server could handle, your scaling capacity topped out. With this limitation of MySQL, the "solution" was to shard customer data. This also meant you had to build some sort of routing mechanism on top of it so when a write request came in, you had to first figure out where the data was. It leads to unnecessary complexity, challenges with primary keys (because now you also have multiple servers simultaneously creating unique records, so you need a new mechanism other than a simple increment for record 1,2,3, etc.), and more database maintenance.
-
Compare this to Cassandra, which was built and designed ahead of time to elegantly scale write transactions across different servers. When you hit the number of write transactions one server could handle, no problem, you add another server and it automatically redistributes the load across all the servers, allowing you to scale writes linearly without adding a router to handle the sharding. It's much harder to build up front - because of the CAP theorom
-
InfluxDB
Access the most powerful time series database as a service. Ingest, store, & analyze all types of time series data in a fully-managed, purpose-built database. Keep data forever with low-cost storage and superior data compression.
Related posts
- A Software Developer's Take: Why Solana is the Biggest Scam in Crypto
- Build Your First App with JavaScript, Node.js, and DataStax Astra DB
- When you should use columnar databases and not Postgres, MySQL, or MongoDB
- Baeldung Series Part 2: Build a Dashboard With Cassandra, Astra and CQL – Mapping Event Data
- System Design: CAP theorem