6 ms·
The situation you describe is more an event then it is an metric, and indeed postgres is much better suited for it, if asked that is what I'd recommend for this
by Licenser 11y ago
The situation you describe is more an event then it is an metric, and indeed postgres is much better suited for it, if asked that is what I'd recommend for this kind of issue.
What DalmatinerDB was build of is handling high numbers of metrics like CPU usage, memory usage, etc, everything where for every point in time you have exactly 1 value. In that space it can handle millions of metrics (read millions of inserts) at the same time where a system like postgres would stat to have problems in my experience.
- losvedir 11y agoI see, thanks for your response!
- TheLogothete 11y agoI wouldn't use postgres for that at all! A NoSQL store is much better suited for that task.
- AlterEgo20 11y agoThere is not suck thing as "NoSQL store". NoSQL is just a buzzword that is used to describe dozens (hundreds?) of very different solutions.
- TheLogothete 11y agoYou are being obtuse. It is obvious what I'm talking about.
- eis 11y agoNo, I don't think it's obvious nor are you right about this.
- TheLogothete 11y agoLook at every mobile gaming company and you will see document stores. Dynamo, BigTable, DocumentDB. Google's very own analytics is built on BigTable. The examples are countless.
- seangrogg 11y agoWhile a document store is a subset of NoSQL databases, NoSQL is not synonymous with document store. It also includes graphs, key-value stores, etc. That's what the original person was getting at - you should've started with "document store". While I may use JSON for storing click data, I wouldn't do it using a NoSQL database.
- spotman 11y agoWhile big table can be classified as a database that can be scaled to extremely large size, I would not recommend it for the backend of a game at all. It would be extremely expensive to run a workload like this, and would not be very performant. This is if we are assuming a very high transaction rate, lots of concurrency and likely highly volatile data. Big table is just not really for that. Either is Dynamo. Both of these are great at giant scale multi purpose databases however.
- eis 11y agoNeither Dynamo nor BigTable are document stores. And there is no reason why Postgres couldn't handle this kind of stuff. Sure it doesn't come with the needed scaling tools built in but it's doable. I'm running billions of rows through a Postgres analytics setup. A purpose built system can be more efficient but it also doesn't need to mean NoSQL. You can see some of the serious-scale datastores adopting SQL-like query interfaces. For example Hive for Hadoop or PlyQL for Druid. NoSQL is a loose term for a mish-mash of technologies.
- TheLogothete 11y agoDynamo started as a document store. Bigtable is not but I included it because it is another very good option for analytics and is still lumped under the nosql umbrella. Using relational database for event analytics means that you have a trivial use case. You might have a lot of rows, but your data is dead simple. Otherwise you would refactor every week to change the schema and sharding. Not to mention how much money you would spend on hardware.
- deleted 11y ago[deleted]
- njharman 11y agoPostgres has a "nosql" store, called hstore.
- zo1 11y agoI hope my sarcasm-meter was accurate when gauging your post as "sarcastic".