« first day (3661 days earlier)      last day (1207 days later) » 

7:00 AM
Morning
 
 
2 hours later…
8:42 AM
Morning
 
8:58 AM
Morning all - Dia dhaoibh a chairde!
Will they ever learn...? <shakes head like father whose child has just proposed his 10th impossible idea of the day>
0
Q: Why big data analytics over peta-byte datasets leads to NoSQL not RDBMS

HovinComputational and storage requirements of applications such as for big data analytics. business intelligence and social networking over peta-byte datasets have pushed SQL-like centralized datasets to their limits. This led to the development of horizontally scalable, distributed non-relational da...

 
9:23 AM
Rereading that question and my comments - I can't help thinking that his VoltDB product is just another sharded database - anybody care to reflect on that? Stonebraker, AFAICS, appears to think that columnar stores are for OLAP and sharded dbs are for OLTP... but he is adamant about keeping ACID and SQL!
 
o/ dia is mhuire, didn't realise you were Irish @Vérace
 
9:50 AM
@Shaneis Dia is Mhuire agus Pádraig dhuit a chara! Currently "Heap"-ing out of Dublin - vary between there and Kildare (fiancée's place) - am about to go for my (late) morning perambulation - within 5K - but I have piers and beaches right beside me, so it's not too bad! You?
 
Ha! Galway-born, Limerick-based, Dublin-Company - I'm so cosmopolitan! :D
 
 
4 hours later…
2:18 PM
morning Heapers
 
3:06 PM
Morning
@Vérace I'm always skeptical of anyone who thinks they can optimize too far beyond what we have today - yes, partitioning can help in certain ad-hoc query workloads, but generally not as implemented today (row identifiers associating heaps of data versus copies of the actual primary key, preferably clustered). It also gets weird when people try to conflate file stores and databases, and think that having lots of rows (from poor normalization/row versioning) constitutes "big data".
We have something like 15-20 TB in a Teradata appliance, but 90% of the rows are copies of other rows.
Not properly normalized, etc. You could achieve the same in a 4-5 TB database on SQL Server, Sybase, or DB2 and get better performance.
Also confusion that DB workloads are trivially parallelizable. Might work for your database of marketing/sales info with a strict hierarchy, anything else it'll choke.
 
@bbaird Hmmm... interesting - so does Teradata denormalise "under the hood"?
 
@Vérace No, we just had bad data modelers. Teradata, of the "big data" appliances is the most faithful to a RDBMS (supports primary keys, foreign keys, etc.), but the data is distributed across AMPs (storage/processing nodes) which gets messy if you're merging large tables that are organized differently.
 
@bbaird "that DB workloads are trivially parallelizable" - I know that VoltDB has to do "tricks" when a query is cross-shard (read about it a while ago - yrs) - not sure of situation now. Agree with you that they're not BTW!
 
@Vérace There are ways to make it work if the data volumes are small - teradata distributes the data based on hash which can be used to do the equivalent of row lookups if the amount of data is small. But if you have a multi-part key, you can only lookup based on the entire key, not a portion (like you would be able to with a b-tree)
 
3:28 PM
@bbaird It's coming back to me - I think there [is | was] a mechanism for hiving OLAP work (in the paid version, not the F/LOSS bit - does that exist anymore?) to, wait for it,... Vertica (IIRC) - another Stonebraker product...
 

« first day (3661 days earlier)      last day (1207 days later) »