Which DBMS to Choose and Why? (Part 2)
After posting “How to Сhoose a DBMS to Solve Your Tasks (Part 1)” I received fair comments about not mentioning DBMS types such as Time Series and Spatial. In this article, I’ll briefly describe them and add two more types –Search engines and Object-oriented.
Let me remind you that the previous article described:
- Relational
- Key-value
- Document
- Graph
- Column-oriented
This post touches upon:
- Time Series
- Spatial
- Search engines
- Object-oriented
Just like in the previous article, you can find the summary table at the end of the text. The table contains all types of DBMS we talked about earlier, plus the ones we will discuss today. If you’re only interested in a compact compilation (type, when to choose, popular DBMS of this type) — scroll through the text to the very end.
Time Series DBMS
This DBMS is optimized for storing time-stamped or time-series data. Time series data can contain measurements or events that are tracked, collected, or combined over a period of time. This could be data collected from motion tracking sensors, JVM metrics from Java applications, market trading data, network data, API responses, process uptime, etc.
Data is stored with timestamps — this is a key feature. Also, data is indexed and written so that it is possible to query this time series data much faster than when used in a classic relational database.
The most well-known DBMS of this type are: InfluxDB, Kdb+, Prometheus, TimescaleDB, QuestDB, AWS Timestream, OpenTSDB, GridDB.
When to choose Time Series DBMS
The primary field to apply such DBMS are monitoring, telemetry handling, and financial systems.
When you shouldn’t choose Time Series DBMS
Refrain from using such a DBMS for tasks that do not involve time series and timestamps.
Object-Oriented DBMS
As the name suggests, this DBMS is optimized for storing and handling objects. As in the case with OOP (Object-oriented Programming), these objects have properties and methods in the DBMS. They also implement encapsulation and polymorphism. The main goal of using object DBMS is to ease life for developers who use the object programming model. Developers won’t have to transform objects into tables, rows with their relationships and back.
Bright representatives of this type of DBMS are: MongoDB Realm, InterSystems Caché, ObjectStore, Actian NoSQL DB, Objectivity/DB.
When to choose Object DBMS
Honestly, I haven’t seen many successful implementations that use object DBMS. However, object databases are generally recommended for high-performance object manipulation that has a complex structure. At the same time, development involves object-oriented programming languages. Some of the common applications that use object databases are real-time systems, architectural & engineering for 3D modeling, telecommunications, and scientific products, molecular science, and astronomy.
When you shouldn’t choose Object DBMS
Do not choose an object DBMS if you plan to use a classic SQL language, if you don’t use OOP, or if there are any plans to migrate from this database to another one. If you don’t have a deep understanding of OOP, in most cases you should opt for document-oriented DBMS.
Search Engine DBMS
This type of DBMS is used to provide full-text searches. Moreover, searches can be made on different data such as data from other DBs, e-mail, RSS-feed, text, JSON, XML, CSV, and even PDF and MS Office documents. Search engine DBMS has its own optimized approaches to indexing data. This includes the use of so-called inverted and faceted indexes to provide near real-time searches. Different DBMS of this type may use different query languages.
Well-known DBMS of this type are: Apache Solr, Elasticsearch, Splunk.
When to choose Search Engine DBMS
Suitable for fast full-text searches across a variety of data sources, structured, semi-structured, and unstructured data Log collection and log search systems are perfect examples.
When you shouldn’t choose Search Engine DBMS
If you search across a limited number of structured data fields.
Spatial DBMS
This type of DBMS is optimized to work with objects defined in geometric space. These can be simple objects (points, curves, polygons) or complex objects (3D objects, topological coverage, linear networks). This DBMS has a set of special functions to process creation, transformation, measurement (distance, area, volume), computation (intersection/contact), and selections based on certain criteria. In such DBMS, there are special indexes that optimize the handling of objects and a special standardized SQL/MM language.
Notable representatives of this type of DBMS: Oracle Spatial, Microsoft SQL, PostGIS, Spatiallite.
When to choose Spatial DBMS
If you’re building GIS solutions, you plan to not just store, but also work with geometry objects at the DBMS level.
When you shouldn’t choose Spatial DBMS
If you plan to simply store geometry objects as coordinates.
Conclusion
We have added four more DBMS types to our list: Time series, Object-oriented, Search Engines, and Spatial. This is still not a complete list, and we will continue working on it in one of the upcoming articles. In future articles, we will consider several large vendors that offer many types of DBMS at once.
Here is the link to a previous post:
I love helping organizations to empower their businesses with data, so I’d love to hear your thoughts on the above in the comments below, and feel free to connect with me on LinkedIn.
