acn_ht_en
| Topic List |
| Database alternatives evaluation (SQL vs NoSQL) | | Migrating SQL to NoSQL database |
| Forums List |
| Scrum: Why What How | | Breakdown Structure Method (BSM) | | Insights my php mysql websites | | Real-Time Big-Data Analytics Technologies | | Information systems design |
|
Database alternatives evaluation (SQL vs NoSQL) |
 Gideon Koch
|
| Database alternatives evaluation (SQL vs NoSQL)
Today many organization utilizes this technology to improve their goals and impact.
Information systems progressed rapidly during the last years and allowed the use of databases in many configurations.
A wise choice of alternative includes impact on the following:
1. Shortening development time Agile base to provide fast implementation
2. Enable adding or upgrading hardware infrastructure without downtime
3. Increases availability of your site using a redundant (document base) structure
4. Speed up response time adapted to geolocation and surfer use
5. Enormous expansion options horizontally and vertically
6. Ability to make changes to the database on an ongoing basis even after the development is complete
7. Zero (not at all) downtime
Three assessments areas:
1. ACID vs CAP-theorem / BASE-implementation options
1.1 Information consistency (when updating data all the user will get the same information right the way)
1.2 Availability for the user (a very short time that the information is presented to the user)
1.3 Access speed using partitions (a way to store your entire data in many servers, each holding part of the information)
2. Size in different forms
3. Data growth vertical and horizontal
4. Geolocation of the site surfers
Evaluating database activity
> Information reliability required
> Normalization required levels 1-3 (in some cases also 4-5)
> Availability of information for end-users
> The importance of geographical targeting (the importance of the availability of the type of information according to geographical location)
> Promotes individual or systemic input activity (document update versus multiple number update)
> The coefficient of doubling the optimal information (some fields will remain empty and unused in the face of optimal use of a field for a purpose other than its purpose or non-existence of information at all)
> Increase and changes in expected data occupancy (horizontal increase)
> Growing and adding records (vertical growing)
> Adding connections in the information system (vertical growth versus horizontal growth)
Estimating the size of the database expansion rate
> Average base document growth
> Document size versus table size (redundancy of fields versus lack of future information)
> Expected database size of each replication if partitioned per geolocation
> Distribution of information (on multiple servers)
> Backup processes
Infrastructure, server, and communication evaluation
Database Engine Type (Does the engine handle NoSQL queries or does it just pull client-side strings)
This figure is critical because if the database engine handles the extraction of JSON information from the documents, there is a load on the processor below but the information transmitted in the media will be "thinner". If no doers were used in the engine that knows how to retrieve a field from the document but transfer an entire document, the processor will be less cluttered but the communication will require greater bandwidth.
Communication traffic (the amount of information passing through the communication channels is compressed)
The text-based information (as opposed to images, sound, or video) is compressed and does not constitute a significant burden on the media.
Communication efficiency (the amount of information that passes without the need to the user. This issue will be discussed later and it is necessary to make accurate calculations of load balancing between the server, user, and communication)
In many cases where SELECT * FROM queries are made, many fields are passed that are not required. A similar thing happens when you move an entire document in NoSQL to retrieve only certain information. Too much communication will overload the system. The performance of these topics is related to the code writers and how they write their retrieval functions.
Server load (JSON queries consume parallel processing power)
The load on the server is expressed in several aspects:
Raw Information - IO - In an age where most of the available database is stored in fast memory this issue has become less problematic in recent years.
File size required for transfer
Simultaneous activities - each computer has its own performance limits and the issue is cold to a wide range of physical system components.
Locks to perform complex transactions - If there are complex queries, the issue can cause delays in the execution of many parallel activities.
Processing - NoSQL retrievals require more processing power than a standard server
The processing power of the server differs from its retrieval capacity
Server synchronization processes (in a distributed configuration) require processing power, communication bandwidth, and disk io.
If the required information accuracy in all distributed hosting servers, required to be immediate (ACID), the subject can cause a rather complex bottleneck.
| | Check out our SQL-NoSQL online evaluator
|
For a well-founded assessment of the structure of the database contact the author using the name on top of this article.
A good alternative is, to set up a relational database stored in distributed partitions.
Vertical or horizontal partitions are used to distribute a table across multiple servers for higher access speeds.
The partition update is performed by the database engine, in a way that is transparent to the user but takes time (a few seconds sometimes).
To fill in the document, it is recommended to rely on a specialist, which has hands-on on both SQL and NoSQL databases. |
|
|
|