#Issue127
2 posts

How to choose the right database

Relational (SQL-based) databases - such as MySQL, PostgreSQL, Oracle, and MS SQL Server - can be queried with SQL-like languages. They allow indexing and faster updating, but total querying time can be slow for large tables.
Read more

How to choose the right database

  • Relational (SQL-based) databases - such as MySQL, PostgreSQL, Oracle, and MS SQL Server - can be queried with SQL-like languages. They allow indexing and faster updating, but total querying time can be slow for large tables.
  • Their simple structure matches most data types and they support atomic transactions but not OOP-based objects. They require vertical scaling (10-100TB), which requires downtime when adding resources to machines.
  • NoSQL databases typically use JSON records with no common schema. There are four main types of NoSQL databases.
  • Document-oriented databases make each document into a JSON and allow indexing by field (so all records must have that field); they support big data analytics using parallel computations (examples are MongoDB, CouchDB, and DocumentDB).
  • Columnar databases store data by the column (querying by subsets of a column is fast), allowing better data compression. They are commonly used for data modeling and logging (an example is Cassandra).
  • Key-value databases allow only key-based querying, which is fast, and each record has a ‘time to live’ (TTL) field deciding when it gets deleted. They are great for caching, but because of using RAM storage, are expensive (examples include Redis and Memcached).
  • Graph databases use nodes to represent entities and edges to represent their relationship; they are good for knowledge graphs and social networks (examples include Neo4J or InfiniteGraph).

Full post here, 7 mins read

Growing your tech stack: when to say no

Deployment infrastructure tools (monitoring, logging, provisioning, building executables, deploying) are a moderate risk. They automate tasks for the whole team, which means the whole team (and deployment) stops if it breaks.
Read more

Growing your tech stack: when to say no

  • Local developer utilities (one-person programs, testing tools) are very low-risk. They run on your own machine, though a whole team can adopt them, boosting productivity. If not widely used, switching environments is harder and you might compromise uniformity, but it is often a worthwhile trade-off.
  • Deployment infrastructure tools (monitoring, logging, provisioning, building executables, deploying) are a moderate risk. They automate tasks for the whole team, which means the whole team (and deployment) stops if it breaks. But they reduce risk in production/deployment compared to manual set-up and troubleshooting. They constitute a hot area for development and you risk falling behind your competition without them.
  • A new programming language is also a moderate risk. Each language calls for new build tools, libraries, dependency management, packaging, test frameworks, internal DSLs. More than one person must learn them, or you get code no one but the developer understands. Getting your team on board, fast becomes your responsibility. You can mitigate the risk by carefully isolating the experimental code so that it becomes replaceable. Consider the tooling and documentation available before you select a language and whether other people have integrated it into a stack like yours (and written about it). The more languages you use, the greater the cognitive overheads when debugging.
  • Adding a new database is a serious risk. A stateful system of record is critical to your business: if it goes down, you cannot just rewrite it, business stops until you can do a migration. In the worst-case scenario, you lose data. You can mitigate this risk with replication (backup and restore) and migration automation, which you should integrate and test before data enters the system. You need a dedicated team to maintain the database (monitoring, updating, re-provisioning) as load increases.

Full post here , 13 mins read