PlanetMysql.ru — информация о СУБД MySQL

This is the third blog post in a series designed to assist companies who wish to migrate their code from Oracle to MySQL. You can read the previous post here.

I went over some of the difficult topics you’ll face when migrating from Oracle to MySQL. However, I left out the topic of database scalability (after all – this is a ScaleBase blog).

Oracle users are used to having a very clear scalability path. You start with an Oracle Standard edition, and if your budget allows, you increase hardware (memory, CPU), improve your storage speed, buy Oracle Enterprise edition and use portioning. If all that fails, you move to a distributed RAC environment. If you’re really on the high end, you buy ExaData2. This is where your journey ends. There is nothing “better”.

That’s great for enterprise applications. The number of users is relatively small, the read ratio is extremely high (>95%), and scale is contained. For most enterprise internal systems the scale is known years in advance.

The “short transaction” model (a term coined by Curt Monash) is radically different. Be it web facing applications, mobile apps, or machine generated content (another Curt Monash term); be it enterprise or startup; it’s impossible to know what the scale will be. The write ratio is very high, since most reads go to a distributed caching layer, to improve query latency – and everybody wants the number of users to increase in a logarithmic scale.

The Oracle scaling solutions just don’t cut it. But in MySQL the situation is even worse.  Developers who are used to “IT handles scaling” suddenly run into scaling limits much faster, then IT throws the hot potato back at them and asks them to write their app so it’s easy to scale!

That’s something you should prepare yourself for when you move to MySQL. IT scaling solutions, although limited in the Oracle world, are non-existent in the MySQL world. Every solution requires code changes, and developers are becoming more and more DevOps.

Or shall I say all but ScaleBase! The ScaleBase solution supports write scaling, a perfect fit for your short-transaction application. And it’s transparent, so it can be implemented by IT rather than by DevOps.

Summary

I started this series by trying to explain why the Oracle database shouldn’t be used for web applications. I continued by explaining what kind of challenges you will face once you decide to migrate. I ended the series by looking at the scalability angle, trying to show how even here Oracle and MySQL differ – and how that effects the IT and R&D processes.

If you plan to migrate from Oracle to MySQL – drop a comment here. I’d love to assist.

PlanetMySQL Voting: Vote UP / Vote DOWN

This is the second blog post in a series designed to assist companies who wish to migrate their code from Oracle to MySQL.

In the first post of the series I tried to explain why you would like your web platform to run on a MySQL database, and not on an Oracle database. In this post, I’ll try to focus on the changes that you need to plan for when migrating from an Oracle environment.

Code

Probably the most obvious change is in code. There is no way around it – you’ll have to change your code.

1. SQL statements.
   While ANSI SQL 92 is a standard, Oracle offers extensions to the spec – and those are used by most developers, sometimes without their being aware of it.
   Of course, when moving to MySQL, those SQL statements will need to change. Some will require only minor changes (For example. When working with paging and wanting to limit number of records returned in a resultset, MySQL’s LIMIT clause will have to replace Oracle’s use of ROWNUM pseudo-variable. OR ANOTHER EXAMPLE: Oracle’s “old” outer join syntax includes (+) near tables in the FROM clause. However since Oracle9i the ANSI join syntax is supported and highly recommended by Oracle themselves!),), but some (like queries using CONNECT BY or many of the aggregate functions Oracle database offers) will require massive query and code changes.
   Even if you use an ORM tool, code changes might be required, although they will probably be much smaller.
2. Stored procedures.
   While stored procedures and triggers are supported by MySQL, they are rarely used. On the other hand, stored procedures are extremely popular in the Oracle database environment – and are very powerful.
   Every stored procedure will have to be migrated, probably manually, to run inside the application. This might result in a major performance hit, since stored procedures run in the database, “close” to the data, and many developers use them for data-crunching tasks.
   All in all, the stored procedures will probably have to be re-designed, not just re-written.

Developers’ “state of mind”

While code can be migrated, and a cost can be attached to such migration, Oracle developers often require some time before they can effectively develop code for MySQL. The limitations mentioned in the above section, and the different development tools, are difficult to get used to.

But even more – it is difficult to get used to what the database does and doesn’t offer. We’ll dive into that topic later, when we talk about scalability and high availability.

DBAs

Oracle and MySQL DBA are similar in title only. Their day-to-day job is very different.

1. Different tools.
   There is no MySQL CLI for Oracle, and SQL-PLUS can’t connect to a MySQL database.
   But those are the minor changes – SQL-Developer and MySQL Workbench are not that different.
   However, backup tools, performance monitoring utilities, and database audits are all very different, and it takes time to get used to those new tools. You should expect that at least some of the tools you currently have in your environment will not support MySQL, and you’ll have to find new tools. For some tasks, those tools are nowhere to be found, and will require in-house development.
2. Scripting.
   DBAs are measured by the quality of their scripts, and most Oracle database environments are heavily scripted. Database start, stop, error fixing, and data collection all use database engine utilities, and all those scripts will have to be rewritten.
3. Tuning parameters.
   A friend once told me about how they migrated their application from Oracle to SQL-Server. It took them three months to migrate the application and six months to tune the database. And this story is not uncommon; tuning parameters vary greatly between databases since every database has a different architecture.
4. Central management and administration. Adding an index, for example. When I have 10 DBs, I have to create on every DB, make sure it succeeded, etc…

High Availability and Scalability

Oracle users know that when they require high availability or high scalability they can turn to RAC. MySQL doesn’t offer such an option; MySQL Cluster is very different from MySQL standalone. We’ll discuss the high availability and scalability topic in our next post.

PlanetMySQL Voting: Vote UP / Vote DOWN

This is the first blog post in a series designed to assist companies who wish to migrate their code from Oracle to MySQL.

During the World War II “Battle of the Bulge”, General McAuliffe said to the German forces who asked for his surrender: “Nuts!” The rest is history – he won the battle, and the allied forces won the war.

Some things are like that. So absurd that “Nuts” is the only possible reaction. And frankly – running your web infrastructure on an Oracle database is one of those things.

Now, the pricing issue is very well covered. Just see here. And for most people, this should be enough. We had a customer migrating from a 7M USD environment to a 200K yearly environment (licensing and support) – definitely worth the migration hassle!

But it’s not just pricing. While my DBA friends might kill me for this, MySQL is actually better than Oracle when it comes to modern environments. The main reason is that Oracle RAC sucks when it comes to scaling writes, while MySQL has tons of scaling alternatives out there (ScaleBase, of course, is the best one, but you’ll be surprised to see that other solutions exist). And writes are what modern applications are all about. Your application stores everything, since everything might be useful. Reads come from the cache anyway.

But Oracle RAC sucks when it comes to write scalability. All the nodes in the Oracle RAC cluster chatter with each other about locking rows and physical storage blocks – so the more writes, the more chatter, the more network data explosion – killing your scalability.

Yeah, I know the SalesForce story.  They have the largest Oracle installation in the known universe. But frankly, SalesForce is not your regular web application; it’s an enterprise application in a SaaS mode. Gaming, web, mail, social – any modern, consumer facing app, just can’t work with Oracle. And how many SaaS companies have the deep pockets that SalesForce has for paying Oracle? (After what Larry Ellison did to Marc Benioff, I wouldn’t be surprised if SalesForce just switched to MySQL or Postgress).

Oh, and Oracle RAC doesn’t even work on virtual environments, so no RAC in the public cloud – probably the most popular environment for web apps these days.

So if your database doesn’t scale, what good does it do for your web application? None.

You pay more – and get less. And almost nobody does that anymore.

In the following installments of this blog I’ll discuss how to migrate from Oracle to MySQL, on both code and experience levels.

PlanetMySQL Voting: Vote UP / Vote DOWN

ScaleBase is happy to sponsor the Percona Live London MySQL Conference. If you plan to attend, you can catch our booth on the expo floor or attend Liran’s session – “The Benefits of Database Sharding” at 2PM, October 25th at the Bishopsgate Suite.

PlanetMySQL Voting: Vote UP / Vote DOWN

In the previous post of this series (which can be found here) I discussed how to migrate your data once you have decided how to shard your schema.

Once your data is sharded, it’s time to modify your application code. I will not dive into the many open source platforms that provide partial sharding support (Hibernate Shards, Gizzard, and the like), and will take Java (sorry, old habits are hard to overcome) as an example – however, the same holds true for any programming language.

Without Using ORM

If you wrote your code without an Object/Relational Mapping tool, kudos to you. Sharding will be easier, as you control the SQL statements.

Upgrading Connection Pool

Your first task is to write a connection pool that is “sharding” aware.  The class should look something like this:

public class ShardingAwareDatasource {
public static Connection getConnection(Object shardingKey) {…}
public static Connection getAnyConnection() {…}
}


Queries that run on specific shards need to use the getConnection method, which must contain the logic that returns the correct connection based on the sharding key. Queries that run on global tables (as described in the previous posts) can use getAnyConnection, which returns a connection to any of the shards.

Note that these methods must be session aware, to ensure transaction isolation.

Changing Queries

1. Go over all of your queries.
2. For each query:
   1. Identify whether it runs on a global or shard table.

i.      If it runs on a global table, make sure the connection used is from getAnyConnection.

1. If it is based on a shard table, check if it contains the shard key.

i.      If so, then use that shard key in the getConnection method.

1. If the query uses other tables, break it down into multiple queries.

ii.      If not, then split the query into multiple queries, so that each contains a shard key.

iii.      Make sure your code merges data that is gathered across multiple queries.

Usually, you’ll see that if the query is not trivial (contains only one table; if the table is sharded, it must contain the shard key in the where clause; etc.) it will have to be changed. It’s a lot of work, but it pays off in performance.

When Using ORM

Since most ORMs don’t support sharding, you’re out of luck. Most likely you’ll have to rewrite your ORM code, directly use SQL, and handle the object mapping by yourself. Not an easy task.

Summary

Implementing your own sharding is not impossible. It’s been done before, and in this series I tried to focus on what tasks are needed when you implement your own sharding.

Of course, if you’re serious about sharding your database, I strongly urge you to give ScaleBase a try. We’ll make sure all this heavy lifting is done for you, in a transparent way – no code changes, no schema configuration, everything is automatic.

I’ll be happy to chat on this page or through our contact us page. Also, you can get more information on how to write your own sharding code in our upcoming webinar. It will be held on November 2^nd, 11AM PST. You can register here.

And if you’d like to find out what’s the best way to shard your schema, try our 100% free Analyzer. You can download it here.

PlanetMySQL Voting: Vote UP / Vote DOWN

In the previous post of this series (which can be found here) I discussed how to identify tables that can serve as good candidates for sharding.

Once you have decided which tables should be sharded (all the rest should be global tables), the choice of sharding keys is rather straightforward, as most will use the table primary key as the shard key. Of course, if multiple tables are sharded, and there is a foreign key relationship between these tables, then the foreign key will serve as the shard key for some tables.

Many people attempt to shard based on customer_id or a resource id, but I have seen how this usually fails in production environments. It is very hard to know in advance which customers belong together in the same database, and since customers can suddenly increase their traffic, this might create an unbalanced situation in which some shards are very busy while others are relaxed (see the details of last year’s FourSquare outage for some possible results of unbalanced sharding).

As with database partitioning, there are multiple algorithms available for sharding: hash , list, or range. Usually you’ll use list and range for multi-tenancy – saving customer information across different databases and maybe even different data centers. I’ll touch on that subject in a future post. But hash will probably give you the best results when it comes to sharding, as statistically it ensures that data is evenly distributed across all shards.

So after sharding configuration, what’s next?

If you have a new application you can skip the next section and just wait for the next post. But if you have an existing database, you’re stuck with huge amounts of data that you need to split.

We at ScaleBase ran a lot of tests and found that the following is the best mechanism for the initial data migration (BTW – if you use ScaleBase,– we handle and also optimize the data migration for you).

1. Have the database cloned in all shards. It can be done by cloning a VM, or copying the physical files, or using mysqldump to export once and import to all shards.
2. For each shard (on shard tables only):
   1. Drop all indexes.
   2. Delete the irrelevant data from the shard (this should be done by an automatic script of course).
      Note: This action creates a lot of fragmentation. You might consider creating temporary a table, inserting to it only the relevant rows, drop the original table and rename the temporary one to the real name
   3. Create all indexes.

In the next post we’ll talk about the programming language modifications that sharding requires.

PlanetMySQL Voting: Vote UP / Vote DOWN

This is the first in a three part series of blogs in which I’ll try to explain how to take an existing application and shard it.

Database Sharding has proven itself a very successful strategy for scaling relational databases. Almost every large web-site/SaaS solution uses sharding when writing to its relational database. The reason is pretty simple – relational database technology is showing its age and just can’t meet today’s requirements: a massive number of operations/second, a lot of open connections (since there are many application servers talking to the database), huge amounts of data, and a very high write ratio (anything over 10% is high when it comes to relational databases).

Many sites and blogs posts explain what sharding is, for example here and here. But how do you shard your application? Actually, the flow is quite simple, and consists of just four steps:

1. Analyze your schema to find the best sharding configuration.
2. Start multiple database instances.
3. Split the data between the databases according to the sharding configuration.
4. Update your application code to support your sharding configuration.

(Alas – it’s incredibly difficult to implement sharding. That’s why we started ScaleBase – but we’re not doing a sales pitch here.)

In this post I’ll explore the first task – analyzing your schema to find the best sharding configuration.

Required Data

To build a sharding configuration, you’ll need the following data:

1. Table list and size
   Big tables are great candidates for sharding since usually many SQL commands are executed on them (otherwise they wouldn’t be so big).
2. List of foreign keys
   Foreign keys can help you understand dependencies between tables. Tables that depend on one another must be divided in a smart enough way, otherwise, your data integrity will be lost.
3. SQL Query log (preferably one that was gathered after running a complete coverage test of the application).
   Some SQL operations are incredibly difficult to implement in a sharded environment (we’ll talk about this in our third post). You need the SQL log to understand whether you can implement sharding on some tables. The SQL log can also give a good indication of which tables are accessed heavily and which are not.

If you need instructions on how to collect this information, you can read our documentation here.

Of course, this section contains an assumption: that the database is well defined and already contains data. This is the easiest course of action. If you have a new database, and you are not sure yet how many rows each table will contain or what the SQL query log will show, you’ll just have to make some kind of educated guess.

Table Policies

Before you begin to implement sharding, it’s important to understand that not every table in the schema will be sharded. Since sharding limits your SQL capabilities (no join between sharded tables, uniqueness, auto-increment columns, etc.), you will enforce limits on your application that will be very difficult to overcome in code.

Usually, some tables will just be replicated across all the shards. As a matter of fact, most tables will be replicated (in ScaleBase, for the sake of discussion, we call these tables Global tables), and only some tables will be sharded. You can read more about table types here.

Deciding which Tables to Shard

The algorithm for choosing which tables to shard is not a very complex one:

1. Look at the biggest tables in your schema.
   There is no exact number of tables to look at. Most schemas have several big tables, and the rest are very small. Table sizes are not divided evenly.
2. Look at the SQL log – are there joins between those tables?
   1. If there are, take the smaller table, and make it a global table.
   2. If not, those tables will serve as your shard environment.
   3. Look at the SQL log
      1. If the tables are not accessed frequently, make them global tables.
      2. Look at the most accessed tables (especially those with many write commands) and mark them as sharded. Go to step 2 to make sure they can be sharded.

The list of tables you get contains the best candidates for sharding. In the next blog post we’ll learn how to migrate your existing data to a sharded environment.

ScaleBase

Just so you’ll know – ScaleBase will soon release a tool that can identify the best sharding policy for your schema. In a few weeks, you’ll be able to download it – and you don’t even have to use ScaleBase or buy a ScaleBase license in order to use it.

PlanetMySQL Voting: Vote UP / Vote DOWN

Backing up data is critical for production databases – and there are a lot of well-known solutions for backing up databases.

When the database is sharded, backing up data becomes problematic. If the backup is not synchronized across all shards, data inconsistency might occur. In this blog post I’ll try to detail the possible backup scenarios for sharded databases when using ScaleBase.

Backup Types

Let’s start by understanding the different backup types that are out there. You can read all about it here.

A physical backup involves copying all database files to a different location. Copying can take several hours for a decent database if it’s done to a disk or a tape. It might take only seconds if the database files reside on SAN/NAS storage hardware that supports snapshot technology.

A logical backup is a copy of the logical database structure. It backs up meaningful data rather than the physical backup’s bits and bytes.  The logical backup is comprised of all CREATE TABLE statements and INSERT statements for the content.

Physical backup methods are faster than logical because they involve only file copying without conversion.

A full restore is also faster from a physical backup. However with a physical backup you can’t restore only one table, or selected specific data. If this is what you need, you’ll have to use logical backups.

Physical Backup

A physical backup can be cold, warm or hot.

Backup Type	Single Database	Sharded Database with ScaleBase
Cold	Shut down the database server. Make the copy or snapshot. Start the database server.	Shut down the ScaleBase instances that are connected to the database (using MySQLAdmin). Take the copy or snapshot (simultaneously) on all sharded databases. Startup the ScaleBase instances.
Warm	Flush and lock all tables with the command “FLUSH TABLES WITH READ LOCK”. Perform the copy or snapshot. Then “UNLOCK TABLES”.	Run the lock command through ScaleBase. While locked, take the copy or snapshot simultaneously on all databases. Run the unlock command through ScaleBase.
Hot	Needs tools like “MySQL Enterprise Backup”, or “Percona xtrabackup”.	Needs tools like “MySQL Enterprise Backup”, or “Percona xtrabackup” on all databases servers.

Logical Backup

1 DB	Sharded
The most common command for a logical backup is:mysqldump –single-transaction –all-databases	Run the command through ScaleBase.

Benefits of Backing Up with ScaleBase

The added value of using ScaleBase when backing up data is:

• Vs. single database:
  • Backup takes only a fraction of the time. Since each database is smaller, copying the data is faster.
• Vs. home-grown sharded environment:
  • Instead of updating backup scripts, just change the IP address to ScaleBase. Everything will continue working exactly as before.

PlanetMySQL Voting: Vote UP / Vote DOWN

Despite my best intentions, I haven't posted on this blog for a while, which is a shame! I've become busy writing on so many other places since I moved into my new role in the Oracle Linux product management team in April. I've learned a lot and I am feeling quite at home here! The team is excellent and very nice to work with — I am slowly getting the "Big Picture".

But even though I've been neglecting this blog, there are a lot of things that are publicly visible and document some of my activites:

I've created two podcasts for the Oracle Linux podcasts:

• OCFS2: Features and Benefits
• Latest Btrfs Updates

In addition to working the @ORCL_Linux Twitter account and FaceBook page, I've been blogging on the Oracle Linux blog:

• Linux Filesystem, Storage and Memory Summit
• Follow us on YouTube and Facebook, too!
• Oracle Linux 6.1 has been released
• Oracle Linux 6.1 ISO images now available for download
• First episode of the Oracle Linux Podcast: Sunil Mushran on OCFS2
• New episode of the Oracle Linux Podcast: Chris Mason on Btrfs
• OTN Sys Admin Days - Oracle Solaris and Oracle Linux (Sep. 8th, Sacramento, CA)

From time to time, I'm a guest blogger on the OTN Garage blog:

• Pimp my Ride - Installing Additional Packages on Oracle Linux
• Save disk space on Linux by cloning files on Btrfs and OCFS2

I also created new content and updated pages on the main Oracle web site and the Oracle Technology Network (OTN):

• A new technical white paper about Oracle Linux and the Unbreakable Enterprise Kernel
• An article about How to Extract Files from an Oracle Linux RPM Package Without Installing the Package
• Added a new page about our Oracle Linux support offering
• Updated the OCFS2 product page
• Updated the Oracle Linux technical information page.

I've been traveling a bit as well and attended a few conferences where I spoke about Oracle Linux (and MySQL):

• MySQL High Availability at COLLABORATE 11, Orlando (FL), USA
• An introduction to Oracle Linux at the HEPiX Spring 2011 Workshop, Darmstadt, Germany
• What's new in MySQL 5.5 at LinuxTag 2011, Berlin Germany
• Updates on Oracle Linux and Oracle VM at fisl12, Porto Alegre, Brazil

I probably forgot a few things in my reflection of the past few months, but these were some of the highlights.

Check out my followup blog post on what I'm up to in the coming weeks and months!

PlanetMySQL Voting: Vote UP / Vote DOWN

The Open DB Camp in Sardinia 2011 has had a number of sessions on varying topics. Topics range from MySQL over MongoDB to replication and High Availability.

I decided to tap into the database expert resources present here at Sardegna Ricerche by discussing a non-database issue, where one can expert database experts to have insights beyond those of end users. And they did.

The topic was the particular case of information overload many of us suffer from on our hard disks: Too many files, too hard to find.

• How do we find the bank statement from April 2007 from the more-seldom-used account?
• What are the ten best work-related pictures from last year?
• Is this the most current version of the presentation of BlackRay?
• Are these films from Cagliari already backed up? Also offsite?

It turned out that I am not the only one suffering from a slight chaos on my hard disk. We all have some basic discipline we try to follow to keep things in order, but the consensus seemed to be that disorder on the hard disk is a psychological problem to be solved by good habits, more than a technical problem to be solved by an application. This in itself is a revolutionary insight, to come from a bunch of techies.

Before going into the individual points, let me first share how I had framed the discussion:

Many OpenSQLCamp attendees spend lots of time communicating about our SQL projects, internally and externally. We spend lots of time architecting database systems, and managing the lifecycle of products.

We do little to implement a proper architecture for the non-database information we create and manage, in business and privately. We drown in emails, digital pictures, versions of downloaded PDF documents, video snippets, and attachments sent by colleagues, partners and private friends. Chaos ensues.

Disorder and low productivity are inevitable unless we are very disciplined in following some basic rules for keeping order on our hard disks, pods and pads. But what are those basic rules? And what tools can implement them?

I don't sit in with more than a rough first sketch of "an Information Lifecycle Architecture", but I'd like to share ideas, thoughts and attitudes with my fellow OpenSQLCamp attendees. I'll present some slides and guidelines, and will make an attempt at collecting your thoughts into a summary afterwards!

I threw in a couple of basic ideas on how to handle the type of information that we have to manage as individuals, usually on our own hard disks:

1. Separate /pub from /rep: Store raw information in its original form in one directory tree, the "repository". Store distilled information ready to be consumed in a separate directory tree, the "publications".
2. Limit the allowed /pub formats: Allow very few formats for publishing (such as .jpg .mov .pdf .mp3 .ogg but not .doc .ppt .xls .cr2 .psd .oo3 or anything even more "exotic").
3. Delete systematically: Don't save many versions of the same file. Don't save information that isn't needed.
4. Sync easily: Set up the directories (and configure your software) so that it's very easy to sync the published files with your mobile devices (Androids, iPhones, iPads, iPods, digi frames), regardless if PDFs, JPGs, MOVs or MP3s.
5. Order files by type: Above /pub and /rep, separate files by rough category: Pictures, Movies, Documents, Music.
6. Order files by year: Under /pub and /rep, separate most files into directories by year. Month or quarter would be too frequent for most personal information.
7. Order files by common sense: Under the year (or in exceptional cases directly under /pub or /rep), separate files by placing them into a smart directory structure, which you yourself decide about according to the topic, as opposed to delegating the file structure to the random preferences of some software (like iPhoto).

Beat Vontobel, Liz van Dijk, Markus Popp, Sheeri Kritzer Cabral, Sergei Golubchik, René Cannao and others came with very good ideas and anecdotes. Let me here relate some of them, while they're in fresh memory:

1. Blog your notes! Write your personal notes so that they're reusable for others. Publish them on your blog. Then you can use Google to find your own notes. I think this tip is smarter than what it sounds at first, i.e. it's applicable for quite a few situations.
2. Use version control! For some who are familiar with version control anyway, it may make sense to put presentations and various types of other personal information into a version control system.
3. Use the cloud! Put some of the information onto the cloud, for easy availability across machines, for easy synching, for backup.
4. Tags for fields should be part of the operating system. You could tag expense reports, notes, contacts, pictures, films, documents and emails alike with #opendbcamp. The tagging should ideally work across operating systems.
5. Order needs discipline. Any good habit of keeping order on the hard disk needs to be backed up by a commitment in time. If you slip once, and twice, and one more time, the discipline is lacking.
6. Storage is cheap. Or is it? Here I noted two schools of thought. One would rather just tag anything and keep order by sorting. The other school would rather delete as much as possible, so that the remainder is smaller and hence easier to keep ordered. I belong to the latter one.
7. Bad banks throw important yet unstructured information at you. You can get a bank account statement with a long filename which doesn't denote the year and month or bank account. You yourself have to parse the file, and name it properly. That's a burden even for a geeky OpenDBCamp visitor. Think of the poor average bank customers!
8. The analog world forced you to have a physical relationship to your data. In order to use your CDs or spices or books, your mental maps of organising them were backed up by some physical structure. This physical structure is missing from digital data. It becomes easier to forget that you even have the information. We end up with a lot of pictures, music and videos we never use.
9. Use Yojimbo http://www.barebones.com/products/yojimbo/ as an information organiser, if you're a Mac user.
10. Does technology solve issues or create them? Earlier, we didn't have as many pics, films, CDs or books. Now, we have more of them, in a variety of forms. Does it really make sense to spend tens of hours sorting and otherwise maintaining your collections (of films, music, pictures)? Or is it better to have smaller collections, even of the seemingly "free" items such as digital pictures and films taken by yourself?

On that philosophic observation, let me end my personal notes from the "Information Lifecycle Architecture" session at the Open DB Camp, which I have now published and will be able to find later on by Googling it.
PlanetMySQL Voting: Vote UP / Vote DOWN