Three sub-problems
The Fundamental Scalability Problem of Data 2.0, leads to three major questions (sub-problems) that need to be solved in the time of transition from the Old World of Data 1.0 to the Brave New World of Data 2.0.
These three questions are :-
a) If we use relational databases how do we build scalable data architectures for tagschema?
b) At the database level how do we add tagging capability to existing non-tag apps?
c) If we move beyond the relational database for tagapps, then what are the characteristics of the new database architectures?
Things to think about. Meaty problems. Massive opportunities at many levels.
May you live in interesting times too.
These three questions are :-
a) If we use relational databases how do we build scalable data architectures for tagschema?
b) At the database level how do we add tagging capability to existing non-tag apps?
c) If we move beyond the relational database for tagapps, then what are the characteristics of the new database architectures?
Things to think about. Meaty problems. Massive opportunities at many levels.
May you live in interesting times too.
posted by Nitin at 10:42 PM
1 Comments:
I have been working on this issue for a week or so. It will be the 'n'th system I've developed, so I am trying to think better, newer, fresher.
I have read maybe a dozen technical articles, white-papers, spec analysis. And I am, profoundly, astonished by the brilliant conclusion of "it all depends on what you want to do and how you want to do it" I have found at the final paragraphs of all. It is almost like all those researches were done to prove that a research has been done, and it had to be done; alas, there is no significant result, no prime solution - but the research itself. This amuses me: with all the advances in almost all aspects of software development there is no simple way out of a "group by" clause, which I believe is the way that the db engine's way of making fun of me.
The most "elegant" solution is the one that performs the worst: multi table relational approach; and the best performing solution is the most nightmarish one: single column dedicated to tags on the "item" table, word breakers for parsing tags, redundant and duplicate data columns for free-text indexes, fragmented data shards that needs baby sitting constantly for fast grouping, and pre-calculated "clouds" that are "near" real time.
Yes, I agree. It is a challenge indeed (in need?). And it is up to the individual architect to come up with the construction method along with the invention of construction tools.
How gauche :)
Post a Comment
<< Home