5 ms·

"He said he had never heard of that and did not know and understand why people were doing that." Could you explain the advantage of having a middle man between

• gaius 18y ago
  Let's say you have a 10,000 logged-in users on your website, of which 1000 are concurrently active. That's very difficult to do with a RDBMS, because (most) RDBMSs do a lot of work to start a session, and maintain an awful lot of session state (for example, Oracle pre-allocates a chunk of memory private to each session to do sorting in). So you put something in the middle, that multiplexes those sessions down into say 100 session on the database, checking connections in and out of a pool as necessary, queueing requests asynchronously if there are no free connections in the pool. You avoid the expensive creation/destruction of database sessions, as you start the sessions when the middle tier starts and keep them, and you keep the session state the database has to maintain at an optimal level. Cleverer architectures add effectively another layer between the middle tier and the database to cache query results (because you the developer can know what data you can cache like that, but the database can only make a best guess). In "sharding" I suppose the middle tier also has to do some logic to figure out which "shard" to direct the query to. Note that this logic must be done, whether you do it yourself in your code, or you let Oracle do it for you in the query optimizer, picking the right partition(s) to actually execute the SQL on.
  • st3fan 18y ago
    This is not what is usually meant by a third tier. Personally I take database connection pooling for granted. What I mean when I talk about a 'data-tier' is the code that deals with accessing data without knowing in whatever datastore it is contained. If you properly hide for example Twitter#getRecentMessagesForUserById(userId) behind a (Java) interface then you can easily change from an implementation where you do direct database calls to a sharded solution or a cached solution. Other tiers that use this API will simply work because the interface has not changed. One day your app could be talking directly to a single MySQL database and the other day your app could be talking to a 60 node PostgreSQL cluster. It would never know since the details are hidden. This is totally against what you see in every Rails book or example app where the first thing that is done is direct ActiveRecord queries. Yes it is more work, but it pays off in the long term. It also greatly reduces local hacks for caching. All that is done in the right place. And automatically for all users of that tier. S.
    • melvinram 18y ago
      Maybe I'm misunderstanding what your saying but I'd like to point out that I can go from MySQL to PostgreSQL in a matter of minutes. Specifically, I would need to change my database.yml file with my new database info and run a migration. Did I miss something?
      • gaius 18y ago
        A slight tangent, but I never understood the philosophy of being database-agnostic. Every database has its own set of features and does things in a certain way. For example, in some databases cursor operations are expensive and temporary tables are the way to go. In some, the opposite. Remaining neutral means using only the most basic SQL and still you might not get the expected performance...