Scribd
Upload
3 views

NoSQL Data Model Comparision

Uploaded by

Minh Tuấn
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
3 views

NoSQL Data Model Comparision

Uploaded by

Minh Tuấn
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

1.

Table-like schema support (columns)


- Column-Oriented: Yes. These databases store data in columns rather than
rows, making them ideal for analytics and operations that require aggregation
across many rows.
- Document Store: No. These databases use a document-oriented model
where data is stored in documents (typically JSON, BSON, etc.) rather than
traditional tables with rows and columns.
- Key Value Store: No. These databases store data as a collection of key-
value pairs without a predefined schema.
- Graph: Yes. Graph databases can support a tabular view of data in terms of
nodes and relationships, which can have properties stored in a structured
format.

2. Complete update/fetch
- All types generally support complete fetch and update operations, meaning
you can retrieve or modify entire entries at once.

3. Partial update/fetch
- Column-Oriented: Yes. Supports efficient partial reads and updates due to
its columnar storage architecture.
- Document Store: Yes. Can fetch or update parts of a document without
needing to read or write the entire document.
- Key Value Store: Yes. Although typically entire values are retrieved or
updated, some systems allow for operations on sub-elements.
- Graph: No. Typically, operations in graph databases involve entire nodes or
relationships rather than partial structures.

4. Query/Filter on value
- Column-Oriented: Yes. Highly efficient at operations that filter by column
values.
- Document Store: Yes. Supports complex queries on the document contents,
often similar to SQL-like querying capabilities.
- Key Value Store: No. These databases are typically not designed for
querying beyond exact key matches.
- Graph: Yes. Can perform complex queries based on node properties and
relationship patterns.

5. Aggregates across rows


- Column-Oriented: Yes. Optimized for running aggregates over large
datasets stored in columns.
- Others: No. These database types are not typically optimized for this kind of
operation without additional processing or indexing layers.

6. Relationships between entities


- Column-Oriented: No. Not inherently designed to handle relationships; joins
and relationships are typically managed at the application level or using SQL
engines.
- Graph: Yes. Specifically designed to store and query data as relationships
(edges) between entities (nodes).

7. Cross-entity view support


- Column-Oriented: No. Views across different entities (tables) are not
natively supported without additional layers or integrations.
- Others: No. Similarly, these systems typically require additional processing
or tools to create combined views across separate data entities.

8. Batch fetch
- All Types: Yes. All support fetching multiple entries in a single operation,
which is crucial for performance in bulk operations.

9. Batch update
- Column-Oriented: Yes. Columnar storage benefits greatly from batch
processing operations.
- Document Store: Yes. Can update multiple documents in one operation.
- Key Value Store: Yes. Supports batch updates of multiple key-value pairs.
- Graph: No. Graph databases generally do not support batch updates as
standard; this would typically require custom transaction handling or specific
API support.

These distinctions help in choosing the right database type based on specific
application requirements, such as the need for fast read/write operations,
support for complex queries, handling large volumes of relationships, or
efficient aggregation processing. Each database type has its niche, making it
suitable for different kinds of data models and access patterns.

You might also like