Home
Joel Liu's Library tagged → View Popular, Search in Google
-
Schema-free document databases are in many ways a more natural fit for Web applications than the traditional RDBMS. With interfaces that are natural and convenient for rapid development, and a lack of object-relational mappers and other heavy middleware, applications can be both simpler and more powerful.
-
Another reason to not use a DBMS for a search engine is that typical implementations of transaction-oriented SQL databases are a terrible fit for the performance requirements of a search engine. For example, search engines don't need concurrent writes or ACID transactions, or SQL-like query language; search engines want to optimize for large-scale updates, not small, random writes; typical DBMS index structures (btree) don't work well for search engine indices.
Eric Brewer has an interesting paper that lays out an architecture for a search engine that is consistent with DBMS design principles, but differs significantly in the implementation details:
-
As our database has grown, we have tried to iteratively deal with the scaling issues that come with rapid growth. We did the typical things, like using read slaves and memcache to increase read throughput and sharding our database to improve write throughput. However, as we grew, scaling our existing features to accomodate more traffic turned out to be much less of an issue than adding new features.
- hi - Joel Liu on 2009-02-27
-
Once you code to a schema from multiple applications, you can never effectively change it. Sure, you can try, but it’ll take you 10 times longer than it should. And since half of your apps are developed by programmers who are no longer with the company, you may not even know you needed that column until you drop it and all the sudden the payroll system crashes. On second thought maybe you should leave it alone.
-
"started as a big vertically scaled classic replication tree (well, started as a single box) and soon hit against performance walls in terms of writes (repl gives you more reads, same writes as slowest machine in your tree). when we started, we barely knew anything about how mysql works with indexes (the documentation is fairly non-beginner), so months of index wrangling to get better performance ensued.
Further, the design of Amazon's database is remarkably like the internal data structures of modern programming languages. Very much like a hash or a dictionary (what Perl and Python call these structures) or Frontier's tables, but unlike them, you can have multiple values with the same name. In this way it's like XML. I imagine all languages have had to accomodate this feature of XML (we did in Frontier), so they should all map pretty well on Amazon's structure. This was gutsy, and I think smart. Permalink to this paragraph
-
A Manila server would work fine for a few thousand sites, but after that it would bog down because the architecture couldn't escape the confines of a single machine it was designed for in the 80s. (Before you say it's obsolete, there still are a lot of apps for single machines. Perl, Python, JavaScript and Java share the same design philosophy.)
-
Firebird is a relational database offering many ANSI SQL-99 features that runs on Linux, Windows, and a variety of Unix platforms. Firebird offers excellent concurrency, high performance, and powerful language support for stored procedures and triggers. It has been used in production systems, under a variety of names since 1981.
Selected Tags
Related Tags
Top Contributors
Groups interested in database
-
Programming Tutorials, Reference, and More!
list of tutorials, reference...
Items: 70 | Visits: 74
Created by: Matt G.
-
Online Databases
Some online database and dat...
Items: 11 | Visits: 95
Created by: smckearney
Diigo is about better ways to research, share and collaborate on information. Learn more »
Join Diigo