11–20 of 24 posts
Can someone explain why one can't simply average the individual average results as the author wrote below: "" No, we can't run averages on worker nodes, and then average those out. We need to have each worker node compute their sum(order_value) and count(order_value), and then sum(sum()) / sum(count()) on the coordinator node. ""? Thank you.
Set 2 (5,7) = 6 average
Average of average (4,6) = 5
Average of Set 1 + Set 2 (5,4,3,5,7) = 4.8
I'd be interested in what Datomic's approach looks like in comparison.
Citus is a distributed relational database vs. Datanomic is a non-relational database.
Citus uses SQL as its query language vs. Datanomic uses Datalog.
Both support joins.
Citus is built on PostgreSQL as its data storage layer. Datanomic supports multiple storage layers.
There are more differences that can be found via Google.
Let me ask you this - how would I use citusdb in such a way that it does not become a tax on my growth? In other words, big data usually precedes big revenue, but most data products are priced per datum not per revenue. So to put in indelicately, who can afford this and if they could, why would they? (after all those who could afford it, eg: bloomberg have strong reasons not to)
Umur from Citus here. Our goal is to make CitusDB an enabler for your growth by making scaling out simple for you and your dev, ops and analyst teams. If we've made it a tax instead and haven't saved you significant time, effort and complexity in the process, we're not doing our job. At a practical level, we offer several ways to accomplish this: - We provide free, open-source extensions on standard PostgreSQL (pg_sh…
Your pricing page tells me you will charge me as much as you think I can afford, so Oracle kind of is the elephant in the room here.
I'd be interested in what Datomic's approach looks like in comparison.
From what I gather, underneath Datomic is an event sourcing database, which is a model that already scales "for free". Further optimization is the fact the query engine lies on the application, so if you have N application servers you have N CPUs available for querying - as opposed to overloading a master server or having to provision read slaves.
I'd be interested in what Datomic's approach looks like in comparison.
Datomic is designed such that load from analytic queries is local to the quering machine (apart from storage retrieval which can be cached and replicated), thus it does not need to be ran on a shadow server or some distanced system from the live production system.
Because the data is immutable in Datomic, there is no need for worrying about locks on tables or documents for contention of future writes--since it reads the data at the time of the query starting from immutable files (joined with the database transaction 'novelty' buffer/log since the last database indexing operation).
It is also up to the querying machine to store the conclusions from such queries in whatever way they like. (If this means going to another datomic instance, or put on HDFS or GFS, by all means.)
Can someone explain why one can't simply average the individual average results as the author wrote below: "" No, we can't run averages on worker nodes, and then average those out. We need to have each worker node compute their sum(order_value) and count(order_value), and then sum(sum()) / sum(count()) on the coordinator node. ""? Thank you.
Division is not commutative, as the article says. A simple example referring to the article's diagram of boxes:
orders_2013 has sum(price) = 10, with 3 records
orders_2014 has sum(price) = 11, with 5 records
orders_2015 has sum(price) = 31, with 7 records
Average on each node, and average them:
( (10/3)+(11/5)+(31/7) ) / 3 = 3.32063492063
Sum the price individually on each node, take the counts on each node, sum them on the master node, and divide on the master node:
(10+11+31)/(3+5+7) = (10+11+31)/15 = 3.46666666667
hence, running division on each node is not the same as finding the division across all orders. (replace my use of division with "average" and it's the same concept).
Earlier quoted context omitted.
Umur from Citus here. Our goal is to make CitusDB an enabler for your growth by making scaling out simple for you and your dev, ops and analyst teams. If we've made it a tax instead and haven't saved you significant time, effort and complexity in the process, we're not doing our job. At a practical level, we offer several ways to accomplish this: - We provide free, open-source extensions on standard PostgreSQL (pg_sh…
What are the advantages of CitusDB over Oracle RAC? Your pricing page tells me you will charge me as much as you think I can afford, so Oracle kind of is the elephant in the room here.
What's the SQL for the second optimized tree?