kfool
Joined 17 years ago
Karma
10
Submissions
52
Member since
Sep 22
Recent submissions
Comment · 14 years ago
Comment · 14 years ago
ChronicDB is not only a hosted solution. It also runs locally.
Comment · 14 years ago
Sorry for not disclosing I work on ChronicDB.
The author of the 6b article kindly provided more information about the time it took for the migration:
http://news.ycombinator.com/item?id=3621561
A couple of limitations of the Percona tool are related to changing data in tables with ON DELETE and ON UPDATE foreign key constraints and possible lock-ups of tables. It is a bi-directional replication tool, so it has to deal with the master-master replication case and as such does not guarantee data consistency.
Still the tool is helpful in many cases and congrats to Percona for developing it. Replication safety is a non-trivial problem in general.
Comment · 14 years ago
The toolkit documentation reports limitations.
What they really needed is ChronicDB http://chronicdb.com
Comment · 14 years ago
NoSQL does not support flexibility of schema change.
http://chronicdb.com/blogs/nosql_is_technologically_inferior....
Flexibility of schema definition and flexibility of schema change are two different things. Defining schemas only involves data. But changing schemas involves not just data, but code too.
Comment · 14 years ago
The issue is not performance. The issue is backward compatibility.
ALTER TABLE performance will eventually improve. PostgreSQL 9.1 lifts-off the lock-up limitation.
But what a performant ALTER TABLE will not improve is its intrusiveness to applications. When you change the schema you break the app.
That's the problem.
Comment · 15 years ago
Which part of the Slicehost to Rackspace migration required the additional time that had not been invested?
Also, what do BCC and AR refer to?
Comment · 15 years ago
Now it's time to bring the idea beyond code
Exactly! Try versioning data with ChronicDB:
When you have the tools you have the power.