Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm trying to determine wether or not to use PostGres or Cassandra data store. Data will be inserted to this new store initially via :
1. A batch process to insert 100MB per day.
2. At a later point the existing batch process + CRUD operations at a rate of 20 operations per second.
From reading articles & various conversations with other I have determined:
**Cassandra**
Type: NoSql
Read Speed: Fast
Write Speed: Slow
Storage: Distributed Cluster
Scaling: Horizontal
**PostGres**
Type: Relational
Storage: Single Instance
Scaling: Horizontal
Some resources I have been reading :
https://www.quora.com/How-do-you-compare-Postgres-to-Cassandra-for-big-data-application
https://www.quora.com/How-do-you-approach-choosing-a-database-architecture-and-design
https://www.thegeekstuff.com/2014/01/sql-vs-nosql-db/?utm_source=tuicool
What other considerations should be taken before making the decision ? Are there other data points I should include in the decision process such as determining the expected number reads, writes, updates, deletes from the table ?
I could utilize PostGres and then migrate to Cassandra at some other point but would prefer to avoid the overhead of a DB migration process.
I work with postgres, because it is more customizable for developers and it is a nosql database combined with the most beautiful parts with sql db.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I was asked this question in this interview:
How to Synch two database data? There will be time delays etc. How do we handle?
The background: I mentioned about Microservice architecture and also using CQRS for performance (Separate Read/get query database) and separate write command database.
Now, if the customer enters or modifies data, how it will be replicated/synched in to the read database?
I was talking about stuffs like cosmos db options etc which prevents dirty read etc. I also mentioned about cache. But I am not certain what are all variousoptions to do synch. Interviewer specifically asked me in SQL DB level how do I synch between two DBs.
CQRS is a pattern which dictates that the responsibility of Command and Query operations be seperated.
Now there are multiple ways you can sychronize the data between databases. You can use Master-Slave Configuration or Oplog Replication Mechanism or something very much specific to the database.
But what's more important here is to decide what strategy to use. Since, you are using CQRS pattern now you have more than one data store (write store, read store) and there are fair chances that these data stores are network partitioned. In which case you would have to decide what really matters to you the most Consistency or Availabililty, which is generally goverened by what businesses require.
So in general, what replication strategy is to be used depends on whether your businesses require Consistency or Availabililty.
References:
CAP Theroem: https://en.wikipedia.org/wiki/CAP_theorem
Replication (Driven by CAP Theorem): https://www.brianstorti.com/replication/
There are a couple of options for database syncing in SQL server.
1. SQL Server Always on Feature (SQL 2012 Onwards) - By using this feature, You need to make a primary and secondary replica (could be multiple secondry replica), Once Always On feature is configured, the Second replicas automatically updated based on Primary replica updates. This also provides HADR feature, if the primary replica goes down, the secondary replica will be active and play primary replica role.
https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-2017
2. SQL Server Replication - Merge replication, Transaction replication etc.
https://learn.microsoft.com/en-us/sql/relational-databases/replication/types-of-replication?view=sql-server-2017
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I am trying to implement sql server database replication between 2 branch servers to a Head Office Server.
My application is a distributed one, the main application is hosted on head office which is controlling the masters and final approvals. The branch servers are located on two other countries, which are used to enter daily transactions.
Since internet bandwidth is too slow, I am planning to run the replication only on off hours (ie.. night 12 AM to Morning 8 AM). During business hours it is difficult to synchronize. All tables are designed such a way to validate and avoid duplication or other errors.
Also there are chances of internet outage for couple of days.. may be up to a week.
There are three type of tables,
BI Directional - Needs to sync between both sides(HO to branch and
branch to HO, Approvals)
Sync from Branch to HO (Transactions)
Sync from HO to Branches (Masters)
When I configure replication, I am confused between different types of replication such as snapshot, transactional and merge replication.
Can anybody suggest which one is the best method for my model
I am also facing some issues with Primary key and foreign keys lost after configuring replication.. Any idea why this is happened..?
Transaction replication is best for one way sync and Merge for Bi directional sync, will be the best options.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
Does it make sense to change from MongoDB to SQL Server in the MEAN full stack (Node Express and Angular)?
In today's data environment, the unfortunate truth is that there is no one "right" data appliance for all use cases. At my last job, we used Hadoop for our streaming data, Couchbase as a web data caching layer, Hive when we needed the illusion of a relational database, SQL Server on Azure when we needed a temporal data store with more than the illusion of relational characteristics, on prem SQL Servers when for the persistence layer where we needed actual relational data, and a Netezza cube for reporting. There's not a handy acronym for that hot mess.
I will say that a lot of shops that are primarily NoSQL focused like Postgres as an RDBMS addition since it keeps with the whole open source philosophy, but your mileage may vary.
The TLDR; answer to your question is that it depends on your use case(s), and there's no avoiding painful hours of research and probably a few false starts before you land on a solution that works for you.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Looking at the prices for RDS instances, the multi-AZ instances cost double. Having a production environment in mind, does it worth it?
What uptime should I expect from a single-AZ instance, as opposed to a multi-AZ one? Has anyone had experience running a production DB on both single and multi availability zones?
We have a multi-AZ production deployment with AWS RDS and it's been working fabulously well for the last 3 years.
The multi-AZ catalog page clearly lists out the benefit of using a multi-az vs single RDS deployment. One of the most important aspects of running multi-az is the fact that if one of the AZ in a region goes down, the production application traffic is automatically routed to the RDS in the alternate AZ. Also, DB maintenance and upgrades are applied to the RDS per AZ basis (for a multi-AZ RDS) without impacting uptime.
With respect to cost, it is totally up to the nature of the application as to how much is the degree of downtime tolerance that it can sustain. It's a cost vs uptime trade-off.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have web application that will be similar to forums. I plan to have few thousands+ users on this application, and i wonder if i can use MS SQL Express - here is the list of it's limitations:
Despite the cpu usage, i wonder if this 1 GB of memory usage is enough. Can anyone tell me if this might be enough, or maybe give me some examples when this 1 GB would be enough.
I think it should be fine. Depending on how many columns you have in each row and their types, you should be able to get at least 1 million rows into 1GB of disk space. The database will only load as much of that table as it needs in memory. If it reaches its memory limit it will start paging.
If you are using SQL 2008 R2, then the actual database can only grow up to 10GB which is the real limit you should be concerned about.
In our database, our tables that are around 1GB contain about 4 million rows. We have 2 databases that are 50GB and the one takes up 16GB of RAM and the other 2GB. So it depends on how often and which tables are accessed.