Cassandra vs Microsoft SQL Server: What are the differences?
Cassandra: A partitioned row store. Rows are organized into tables with a required primary key. Partitioning means that Cassandra can distribute your data across multiple machines in an application-transparent matter. Cassandra will automatically repartition as machines are added and removed from the cluster. Row store means that like relational databases, Cassandra organizes data by rows and columns. The Cassandra Query Language (CQL) is a close relative of SQL; Microsoft SQL Server: A relational database management system developed by Microsoft. Microsoft® SQL Server is a database management and analysis system for e-commerce, line-of-business, and data warehousing solutions.
Cassandra and Microsoft SQL Server can be primarily classified as "Databases" tools.
"Distributed", "High performance" and "High availability" are the key factors why developers consider Cassandra; whereas "Reliable and easy to use", "High performance" and "Great with .net" are the primary reasons why Microsoft SQL Server is favored.
Cassandra is an open source tool with 5.27K GitHub stars and 2.35K GitHub forks. Here's a link to Cassandra's open source repository on GitHub.
According to the StackShare community, Microsoft SQL Server has a broader approval, being mentioned in 478 company stacks & 443 developers stacks; compared to Cassandra, which is listed in 342 company stacks and 239 developer stacks.
What is Cassandra?
What is Microsoft SQL Server?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Cassandra?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
We initially started out with Heroku as our PaaS provider due to a desire to use it by our original developer for our Ruby on Rails application/website at the time. We were finding response times slow, it was painfully slow, sometimes taking 10 seconds to start loading the main page. Moving up to the next "compute" level was going to be very expensive.
We moved our site over to AWS Elastic Beanstalk , not only did response times on the site practically become instant, our cloud bill for the application was cut in half.
In database world we are currently using Amazon RDS for PostgreSQL also, we have both MariaDB and Microsoft SQL Server both hosted on Amazon RDS. The plan is to migrate to AWS Aurora Serverless for all 3 of those database systems.
Additional services we use for our public applications: AWS Lambda, Python, Redis, Memcached, AWS Elastic Load Balancing (ELB), Amazon Elasticsearch Service, Amazon ElastiCache
I am a Microsoft SQL Server programmer who is a bit out of practice. I have been asked to assist on a new project. The overall purpose is to organize a large number of recordings so that they can be searched. I have an enormous music library but my songs are several hours long. I need to include things like time, date and location of the recording. I don't have a problem with the general database design. I have two primary questions:
- I need to use either MySQL or PostgreSQL on a Linux based OS. Which would be better for this application?
- I have not dealt with a sound based data type before. How do I store that and put it in a table? Thank you.
Stitch is a wrapper around a Cassandra database. It has a web application that provides read-access to the counts through an HTTP API. The counts are written to Cassandra in two distinct ways, and it's possible to use either or both of them:
Real-time: For real-time updates, Stitch has a processor application that handles a stream of events coming from a broker and increments the appropriate counts in Cassandra.
Batch: The batch part is a MapReduce job running on Hadoop that reads event logs, calculates the overall totals, and bulk loads this into Cassandra.
We've always counted on SQL Server as our database backend. It has served us well over the years. It isn't the cheapest part of our stack, but with the plethora of tools provided by 3rd parties, we have found an incredible and scalable method of keeping our data available and easy to maintain.
Cassandra is our data management workhorse. It handles all our key-value services, supports time-series data storage and retrieval, securely stores all our audit trails, and backs our Datomic database.
Defacto, industry standard for backend relational databases. Entity Framework makes designing, migrating & maintaining SQL Server databases a breeze. LocalDB is especially helpful during development.
Our core systems that we integrate with are using SQL Server 2012 / 2016 database servers. We use database views on core system databases to help build our domain model.
While we experimented with Cassandra in the past, we are no longer using it. It is, however, open for consideration in future projects.
Main transactional database. SQL Server 2012 Enterprise with AlwaysOn Availability Groups for high availability and disaster recovery.
We are using Cassandra in a few of our apps. One of them is as a count service application to track the number of shares, clicks.. etc