» Business http://palominodb.com/blog Sun, 08 Nov 2009 16:35:29 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 Where we’ve been… http://palominodb.com/blog/2009/11/08/where-weve-been/ http://palominodb.com/blog/2009/11/08/where-weve-been/#comments Sun, 08 Nov 2009 16:35:29 +0000 Administrator http://palominodb.com/blog/?p=25 You might notice that I haven’t blogged in oh, 2 years.  How remiss of me.  The only defense I have is that we’ve been non-stop busy!  Since then we’ve built our client portfolio, brought in two new team members, presented at MySQL Conference and still managed to get into any number of shenanigans.   Still, that is no excuse.  Let me give a summary of some of the interesting things we’ve been up to:

* Helping a client in the midst of a 10x growth period.

* Assisting clients in SOX compliance and acquisition readiness.

* Numerous upgrades to 5.1.

* Integrating Percona xtrahotbackup with MySQL-zrm

* Rolling out and tuning Percona 5.1 binaries w/xtraDB plugin

* Using mk-query-digest to help clients get visibility into their systems without turning on invasive logging.

* Security audits and roll-outs (much to the dismay of developer communities across the world! *evil laugh here*)

* Implementation of a new database historical tracker that combines rancid schema and user monitoring, historical versioning and historical volumetrics. (more on this soon!)

* Breakdancing!

* and much much more.

]]> http://palominodb.com/blog/2009/11/08/where-weve-been/feed/ 0 The Prototype http://palominodb.com/blog/2007/10/15/the-prototype/ http://palominodb.com/blog/2007/10/15/the-prototype/#comments Mon, 15 Oct 2007 02:19:59 +0000 Administrator http://palominodb.com/blog/2007/10/15/the-prototype/ The first start-up stage I’ve worked within is the prototype phase. Within this phase traffic is not an issue for performance or scale, it’s about functionality. Low traffic and small datasets can hide atrocious code quite easily. The nice thing about this stage is that you should not have to invest a lot of time or money into your database and instead can focus on functionality and business development. Over-engineering at this point can be a devastating waste of very precious resources.

Here are the three criteria I would recommend focusing on:

1. Standards – I’m not talking about long lists of rules or apocryphal abbreviations here; rather focus on simplicity, consistency and usability. Don’t make decisions without asking yourself if the choice you’ve made is simple to practice, can be done so consistently, and would be easy for a new employee to use. Without standards, you will find that your database quickly becomes difficult to navigate and utilize – and a headache to maintain. Important standards include database object names, file system layouts, documentation design and locations.
2. Backups – There is nothing more frustrating than losing days or weeks of work. One of the key jobs of a DBA is making sure that your data can be recovered in case of a crisis. From the beginning, you need a solid backup and recovery process. Again, at this stage, nothing elaborate is required. It may be as simple as a nightly dump, or you may need more frequent dumps and perhaps even point in time recovery depending on the amount of change and number of people making the changes. Another key factor here is actually documenting how to perform the restores and practicing them regularly. Backups do fail and sometimes that failure is subtle. Regular practice will help to insure a successful recovery.
3. Documentation – As you make decisions about standards, set up processes, start building scripts, and implement tools and management utilities you need to document them for repeatability. Wikis are great for this, but again you must maintain a culture of discipline in regards to documentation. Tasks should not be completed without documentation and those responsible for doing so must be held accountable for it. This is an excellent way to start building discipline into the culture. As the prototype becomes operational more rigorous processes can build on this, such as change and problem management.
]]> http://palominodb.com/blog/2007/10/15/the-prototype/feed/ 0 The Start-up and the Database – Pt 1 http://palominodb.com/blog/2007/10/06/the-start-up-and-the-database-pt-1/ http://palominodb.com/blog/2007/10/06/the-start-up-and-the-database-pt-1/#comments Sat, 06 Oct 2007 17:10:21 +0000 Administrator http://palominodb.com/blog/2007/10/06/the-start-up-and-the-database-pt-1/ My first senior production database role was at an established start-up, Preview Travel, that had just been purchased by a similarly established, but better positioned start-up, Travelocity. Since then, I’ve worked with start-ups in all stages of growth and I’ve seen definite patterns in how database infrastructures are designed, implemented and maintained (or the lack thereof). I’ve seen these phases of growth presented elsewhere, often at a level of granularity that didn’t work for me. I am a believer of simplicity wherever possible. So, these are the levels of growth as I see them, recognizing that the only generalization you can make is that every situation will be unique:

  1. Prototype
  2. Initial Production
  3. Pain Point 1: Availability
  4. Pain Point 2: Performance
  5. Pain Point 3: Scalability
  6. Maintenance Mode

Each of these phases must be taken with a viewpoint of the entire business. While all of us OCD architects and administrators would absoutely love to design the perfect solution from scratch, it is not realistic for a company on a shoestring budget or that has no clue about the traffic patterns they’ll be driving. Bottlenecks and pain points need to be looked at as indicators of needs for a) growth or b) improved processes. Taken in this manner, one can create a roadmap for growth based on the individual site’s needs rather than busting the budget immediately or optimizing for scenarios that will never occur.

Of course, there is an exception, and that is pain points that compromise a site’s revenue or reputation. Luckily, in 80 – 90% of the scenarios (potentially more!) these are problems that have already been solved to some degree. In the immortal words of Tyler Durden – You are not a beautiful or unique snowflake. That’s where my job comes in, to help utilize those existing lessons learned before investing in new solutions from scratch. Each phase has them, and that’s where I will be focusing my initial posts.

]]> http://palominodb.com/blog/2007/10/06/the-start-up-and-the-database-pt-1/feed/ 0 Preamble http://palominodb.com/blog/2007/10/06/preamble/ http://palominodb.com/blog/2007/10/06/preamble/#comments Sat, 06 Oct 2007 16:31:00 +0000 Administrator http://palominodb.com/blog/2007/10/06/preamble/ I’ve been considering starting a blog of my own for quite some time, but I must admit to some hesitancy, primarily due to the quality of technical content already posted online. Finally, I’ve decided to take the plunge, and to focus on the quality I truly bring to my own customers. Yes, I possess a very solid technical acumen around Oracle and MySQL environments. But, it isn’t technical knowledge alone that can really bring a company to that desired nirvana of availability, performance and scalability, not to mention doing so on a reasonable budget.

So, I’ve decided to focus on the strategy of database design and growth as the theme of my blogging. There will also be some tactical posts, particularly in regards to tools, scenarios and solutions that I’ve come across. My goal with this? To create something that my customers and other web-businesses can use to encourage their creative juices and to be more proactive with their own database infrastructures.

]]> http://palominodb.com/blog/2007/10/06/preamble/feed/ 0