We’re rewarding the question askers & reputations are being recalculated! Read more.
9

If you use Cassandra and need to emulate a lot of JOIN's, then you are doing it wrong. The reason for such a data model is usually that you are following the habit you learned from relational databases and normalize your data as much as possible. This leads to data getting spread out over many tables. This is a bad idea in Cassandra, because you have no ...


8

No startup has ever written the first version of their software with this kind of scalability in mind. Facebook started out in PHP, and wrote a cross-compiler to convert their PHP code to C++ to reduce the number of servers they need by 50%. Twitter made major architectural changes, and got a 3X improvement in speed. In both cases, they started out with ...


5

The architecture is good enough to handle many requests per second, as long as you test it and profile it and it proves to handle the load that it is required to handle. Let me quote Donald Knuth, Computer Programming as an Art, 1974: The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at ...


4

I think that your search results can greatly improve through a number of techniques or database design approaches that will improve performance in your typical RDBMS. I suggest looking into and possibly prototyping the following improvements to see if they help you in performance testing first before you commit to an entirely new database technology that ...


4

Even fetching all details for just one hotel may results in a JOIN query from at least four tables, and scanning over all hotels records. A four-join query is absolutely trivial if you have the appropriate indexes for all joins. The second part of this question is far more troubling. Why the scan over all records? Is is because of missing indexes? or ...


3

Aggregated or analytical data is often immutable, that is, it represents a finalized view of data over a certain time period, or w/r/t to some transformational processing. So perhaps some of your problem stems from post hoc alteration of this data. Denormalized data is common in Cassandra, but maybe it would make sense to maintain the individual items (with ...


3

I am not qualified to judge between MySQL and Cassandra. I know a little MySql but zero about Cassandra. However I have seen many projects in similar situations. An investment has been made in a new technology which is not working out for whatever reason. At some stage, there is a crunch point where the decision hsa to be made on whether to make a ...


2

Why either/or? I've worked very successfully with a hybrid approach, using a relational db (SQL Server, but pick your favourite) to hold data that needs a relational structure - most of this is IDs linking all the various domain objects, very little textual data and certainly no blobs - and a nosql db (Dynamo) to hold large relatively unstructured data, ...


2

NoSQL is generally not very good with relational data. NoSQL is often great for non-relational but structured data like documents or time series. Your "one to many" relationships may look quite like a document: e.g a "hotel" document may carry all its images, room info, etc stored together and fetched with one operation. On the other hand, if you see a ...


2

There's not really a question here, but I happen to have read that paper just now. I'll try to provide my interpretation. This sentence states that Scuttlebut reconciliation will not differ from precise reconciliation if there was no maximum to the size of network messages. Obviously, there is; this is the whole point of coming up with a clever ...


2

If you need to SELECT before UPDATE you are doing it wrong. Cassandra is faster at writing than it is at reading. You will never get 100k writes / s if you need to read before write. I suggest you would use an id for the user. In that case you would not need to update all the other tables when the username changes. Finally, if you don't want to do any of ...


2

Spark programs are just java, scala or python code, so they can write data to all the same places any program can write them. In fact, spark does not actually do anything unless you write the end result somewhere with an output operation. If the end result of a spark job is small, it can be written to a relational database or a web service or something of ...


2

RDBMS vs. NoSQL The question RDBMS vs. NoSQL, despite the claims of some vendors, is not a simple question of performance and scalability. It's a question of structure of your data and what you intend to do with it. If your data is highly structured, you can certainly benefit from an RDBMS, and scale it as needed, by using bigger servers, adding multiple ...


1

Your assumptions are not so much wrong as incomplete. The trade-off between scalability (tolerate network partitions or P in CAP), and transactability (consistency or C in CAP) does not pose itself at the level of a system but at the level of an individual operation or transaction. That is to say, a transaction can be consistent or it can leverage horizontal ...


1

First of all, I highly recommend you take this data modeling course from Datastax. They claim it takes 12 hours, but depending on your prior experience it may take less. It's well worth your time if you're struggling with issues like this. Second, ALLOW FILTERING is almost always a bad idea. It's useful in a limited set of use cases, but magically making ...


1

I won't judge between MySQL and Cassandra for your situation. But it looks like you cannot find another talented Cassandra developer easily... So, unless you are doing experimental stuff and don't mind if it fails in production, go the safe way and continue with MySQL, you will have problems with MySQL as well as you will have problems with Cassandra but at ...


1

If you are familiar with MySQL and your site isn't of incredibly huge magnitude, I'd stay with MySQL for now until there are more resources to look into hiring people well-versed with technologies like Cassandra. MySQL is a great choice for different functionalities due to its pluggable engine architecture. There's a transactional engine using fractal trees ...


1

You can stay relational and be noSQL at the same time if you can partition data(perhaps by time) with playOrm/cassandra so that you can do "scalable JQL" like so @NoSqlQuery(name="findJoinOnNullPartition", query="PARTITIONS t(:partId) select t FROM TABLE as t INNER JOIN t.security as s where s.securityType = :type and t.numShares = :shares") It also ...


1

Part of the issue of NoSQL databases is that they are newish products with very variable feature sets and useage styles. As a result there is no one right way to use a NoSQL database. I have some familularity with Riak, and am of the view that it would support the feature set you are talking about, including expiring your expired gifts. and supports the ...


Only top voted, non community-wiki answers of a minimum length are eligible