19:01 Onsite and Remote - getting best of both worlds » MySQL Performance Blog

At Percona we provide services both Onsite - visiting the customers and Remote - logging in to their systems or communicating via email,phone,instant messaging.

We believe both approaches have their benefits and drawbacks and mixing them right way allows you to get your problems solved most efficient way.

Onsite visits are great as they allow consultant to meet your team in person and great for relationship building. It is great for architecture design and review as you can sit down with the team and use drawing board. It also often allows the best focus both for consultant and for participating team - when consulting visit is arranged it is usually the top priority for some of the staff members which provide consultant with information and assistance he might need.

Onsite visits also often allow to get prompt attention from other team - looking for network engineer to understand network topology or for someone from marketing to get the growth plans - they typically can be brought in for question.

I believe Onsite visits also offer unmatched training experience for the team - one of the team members can work side by side with consultants observing what he does and asking the question about the progress.

The Single Day visits are often extremely valuable as a kick off to do application redesign, for performance review or for starting long term Remote DBA or support relationships. They can be done with little planning as basically for any system there is enough work to spend efficiently understanding the system and working on the pressing problems customer may have. Such visits are often result in a lot of “homework” as application changes or implementing changes on production which when can benefit from remote followups to validate changes and provide further advice.

Multi day onsite visits require a bit more planning to be efficient. Many times in my career I would come to the customer for a week only to find I have created the implementation plan within 1-2 days and it will take a while to implement it and pass it through development and testing stages. Before long onsite visit it is very good to have a call with consultant to understand what exactly needs to be done, how much time and what resources it requires.

Projects which can be efficient as multi day visits are whenever implementation is required (coding unlike giving advice takes a lot of time) - migration projects, any forms of scripting, implementation (writing queries), hands on setting up MySQL, Replication, Monitoring, High Availability with MMM or DRBD are good examples.

Another good example of efficient Multi-Day visit is when there are multiple groups or multiple applications using MySQL - in such case each of the problem areas/groups can gets its own day or few hours which keeps consultant busy.

To make a Multi-Day visit efficient it is important to plan on what will be done - what people will consultant need to work with and which problems do they have. Providing proper access and having staging/test systems available are also often required.

Remote work has a benefit of consultant being available in the short time intervals and being able to multi task.

Working with the customer there are two types of “waits” which are often encountered. First - waiting on the customer. It could be fixing access problems, completing application changes, QA, scheduling downtime to implement changes and millions of other things. Second - waiting on database (or other) operations to complete - backup, restore, ALTER TABLE, load testing - all of these things take time and make consultant to wait for them.

In case you’re working remotely consultant typically has other tasks to do while such long processes are running. If you’re spending time onsite you may have other tasks or you may not while if you’re working remotely there are always things to do.

Another benefit of remote work - it truly allows to engage the team. If you have consultant onsite getting another one with some specific knowledge is complicated while getting another person to login to the system remotely for a quick look is easy and efficient.

Time is another interesting factor - onsite visits usually happen during office hours while changes to production are often avoided. With remote work it is much easier to do work which needs to be done at night hours.

Remote work however also needs to be well organized. The benefit of onsite work is - it is always planned at very specific time. Given date and time consultant will be there so both consultant and customer prepare for the visit. If appointment is just a phone call or online meeting there is larger chance it can be forgotten by ether party. In many cases the remote work not planned to the specific time at all which can cause it to be delayed because of either party delays.

If you need something to be done fast and you’re doing it remotely make sure to plan it to exact time and make sure there is someone to assist consultant if he needs any help such as access issues, some questions about setup or what exactly given queries are doing. Prompt responses can keep the ball rolling much faster.

Another trick to make remote work successful is to be very clear in your instructions especially if you’re not going to be available to assist consultant when he is doing the work. As remote work is often done cross time zones this becomes a very important factor.

In case you have a lot of work done in such “disconnected” mode it is a good idea to have daily/weekly/or be-weekly (depending on project intensity) calls to get team to discuss the progress and generally get team on the same page.

In general surprisingly a lot of things can be done in completely remote mode - we’ve done not only basic optimizations but architecture redesigns, large scale deployment, migrations and high available architectures implementation such a way often surprising customers (in a good way) of how little customers the work took.

The Great Mix As I mentioned before mixing Onsite and Remote work can be indeed the best mix especially for the complex projects. Onsite visit is great to setup relationships, get initial understanding of the system and get initial project planning. After it is done a lot of work can be done remotely quite efficient while there may be the benefit in onsite status-checks and team interactions as well.


Entry posted by peter | No comment

Add to: delicious | digg | reddit | netscape | Google Bookmarks

17:59 Scaling w Flash Webinar Recording Available » MySQL Performance Blog

The Scaling with Flash webinar I’ve mentioned earlier was a success and we got the recording available. It contains Percona presentation, presentation of Schooner appliances and Q&A session. Enjoy.


Entry posted by peter | No comment

Add to: delicious | digg | reddit | netscape | Google Bookmarks

15:47 Using Google Analytics and Website Optimizer Together -- in 60 Seconds » Google Analytics Blog
A couple of months ago, we published a post on making your site a closer. But, before your website can close a sale, it has to get the visitor's attention. Presenting your visitor with a landing page that's relevant to what she's looking for is the best way to start the conversation and proceed towards the conversion or sale. Of course, you'll want to pair your landing pages with the appropriate keywords and ads. But, what else can you do to get more visitors to become customers?

Google Website Optimizer can help you identify the copy, images, and page layout combination that is most effective at getting visitors to convert. The key is to use Google Analytics to find out which landing pages are least effective, so you can start working on those first. Our first Google Analytics + Website Optimizer in 60 Seconds video shows you how.



Do you have a tip on using Google Analytics and Website Optimizer together? Feel free to post a comment and share. And, be sure to check out the techie guide for more advanced Website Optimizer tips.


10:28 It Must be Crap on Relational Dabases Week » High Scalability - Building bigger, faster, more reliable websites.

It's hard to be a relational database lately. After years of faithful service everywhere you look the world is turning against you:

  • Recently at the NoSQL conference 150 revolutionaries met with their new anti-RDBMS arms suppliers. And you know what happens when revolutionaries are motivated, educated, funded, and well armed.
  • The revolution has gone mainstream when Computerworld writes No to SQL? Anti-database movement gains steam. It's not just whispers anymore, it's everywhere.
  • And perennial revolutionary Michael Stonebraker runs from blog to blog shouting the The End of a DBMS Era (Might be Upon Us). Relational vendors are selling legacy software, are 50x slower than other alternatives, and that can not stand.
  • The Greek Chorus on Hacker News sings of anger and lies.

    Certainly some say stick with the past. It's your fault, you aren't doing it right, give us another chance and all will be as it ever was. Some smirk saying this is nothing but a return to a more ancient time when IBM was King.

    But it's in the air. It's in the code. A revolution is coming. To what? That is what is not yet clear.

  • 07:43 Product: Hbase » High Scalability - Building bigger, faster, more reliable websites.

    Update 3: Presentation from the NoSQL Conference: slides, video.
    Update 2: Jim Wilson helps with the Understanding HBase and BigTable by explaining them from a "conceptual standpoint."
    Update: InfoQ interview: HBase Leads Discuss Hadoop, BigTable and Distributed Databases. "MapReduce (both Google's and Hadoop's) is ideal for processing huge amounts of data with sizes that would not fit in a traditional database. Neither is appropriate for transaction/single request processing."

    Hbase is the open source answer to BigTable, Google's highly scalable distributed database. It is built on top of Hadoop (product), which implements functionality similar to Google's GFS and Map/Reduce systems.

    read more

    07:38 Hypertable is a New BigTable Clone that Runs on HDFS or KFS » High Scalability - Building bigger, faster, more reliable websites.

    Update 3: Presentation from the NoSQL conference: slides, video 1, video 2.
    Update 2: The folks at Hypertable would like you to know that Hypertable is now officially sponsored by Baidu, China’s Leading Search Engine. As a sponsor of Hypertable, Baidu has committed an industrious team of engineers, numerous servers, and support
    resources to improve the quality and development of the open source technology.

    Update: InfoQ interview on Hypertable Lead Discusses Hadoop and Distributed Databases. Hypertable differs from HBase in that it is a higher performance implementation of Bigtable.

    Skrentablog gives the heads up on Hypertable, Zvents' open-source BigTable clone. It's written in C++ and can run on top of either HDFS or KFS. Performance looks encouraging at 28M rows of data inserted at a per-node write rate of 7mb/sec.

    07:31 Product: Facebook's Cassandra - A Massive Distributed Store » High Scalability - Building bigger, faster, more reliable websites.

    Update 2: Presentation from the NoSQL conference: slides, video.
    Update: Why you won't be building your killer app on a distributed hash table by Jonathan Ellis. Why I think Cassandra is the most promising of the open-source distributed databases --you get a relatively rich data model and a distribution model that supports efficient range queries. These are not things that can be grafted on top of a simpler DHT foundation, so Cassandra will be useful for a wider variety of applications.

    James Hamilton has published a thorough summary of Facebook's Cassandra, another scalable key-value store for your perusal. It's open source and is described as a "BigTable data model running on a Dynamo-like infrastructure." Cassandra is used in Facebook as an email search system containing 25TB and over 100m mailboxes.

  • Google Code for Cassandra - A Structured Storage System on a P2P Network
  • SIGMOD 2008 Presentation.
  • Video Presentation at Facebook
  • Facebook Engineering Blog for Cassandra
  • Anti-RDBMS: A list of distributed key-value stores
  • Facebook Cassandra Architecture and Design by James Hamilton

  • 07:02 Product: Project Voldemort - A Distributed Database » High Scalability - Building bigger, faster, more reliable websites.

    Update: Presentation from the NoSQL conference: slides, video 1, video 2.

    Project Voldemort is an open source implementation of the basic parts of Dynamo (Amazon’s Highly Available Key-value Store) distributed key-value storage system. LinkedIn is using it in their production environment for "certain high-scalability storage problems where simple functional partitioning is not sufficient."

    read more

    06:53 Anti-RDBMS: A list of distributed key-value stores » High Scalability - Building bigger, faster, more reliable websites.

    Update 2: They are now called NoSQL databases. So keep up! Eric Lai wrote a good article in Computerworld No to SQL? Anti-database movement gains steam about the phenomena. There was even a NoSQL conference. It was unfortunately full by the time I wanted to sign up, but there are presentations by all the major players. Nice Hacker News thread too.
    Update: Some Notes on Distributed Key Stores by Leonard Lin. What's the best way to handle a fast growing system with 100M items that requires low latency and lots of inserts? Leanord takes a trip through several competing systems. The winner was: Tokyo Cabinet.

    Richard Jones has put together a very nice list of various key-value stores around the internets. The list includes: Project Voldemort, Ringo, Scalaris, Kai, Dynomite, MemcacheDB, ThruDB, CouchDB, Cassandra, HBase, and Hypertable. Richard also includes some commentary and their basic components (language, fault tolerance, persistence, client protocol, data model, docs, community).

    There's an excellent discussion in the comments of Paxos vs Vector Clock techniques for synchronizing writes in the face of network failures.

    关于 I/O 的五分钟法则(Five-Minute Rule)DBA notes » 车东's shared items in Google Reader

    作者:Fenng 发布在 dbanotes.net. BLOG 墙外订阅数量,点击则可进行订阅

    去年在对 SSD 做调查的时候就关注过这个五分钟法则,今天又发现了这篇文章的修订版(为了纪念 Jim Gray),这个话题倒是可以简单介绍一下,对架构师衡量 I/O 能力、Cache 评估和做硬件选型还是会有一些帮助的。

    在 1987 年,Jim Gray 与 Gianfranco Putzolu 发表了这个"五分钟法则"的观点,简而言之,如果一条记录频繁被访问,就应该放到内存里,否则的话就应该待在硬盘上按需要再访问。这个临界点就是五分钟。看上去像一条经验性的法则,实际上五分钟的评估标准是根据投入成本判断的,根据当时的硬件发展水准,在内存中保持 1KB 的数据成本相当于硬盘中存储同样大小数据 400 秒的开销(接近五分钟)。这个法则在 1997 年左右的时候进行过一次回顾,证实了五分钟法则依然有效(硬盘、内存实际上没有质的飞跃),而这次的回顾则是针对 SSD 这个"新的旧硬件"可能带来的影响。

    graefe_table3.gif

    随着闪存时代的来临,五分钟法则一分为二:是把 SSD 当成较慢的内存(extended buffer pool )使用还是当成较快的硬盘(extended disk)使用。小内存页在内存和闪存之间的移动对比大内存页在闪存和磁盘之间的移动。在这个法则首次提出的 20 年之后,在闪存时代,5 分钟法则依然有效,只不过适合更大的内存页(适合 64KB 的页,这个页大小的变化恰恰体现了计算机硬件工艺的发展,以及带宽、延时)。

    根据数据结构和数据特点的不同,对于文件系统来说, 操作系统倾向于将 SSD 当作瞬时内存(cache)来使用。而对于数据库,倾向于将 SSD 当作一致性存储来用。

    这是一篇非常重要的文章(所以,建议读一下原文),其中对于数据库一节的描述尤其有趣(针对 DB 也有个五分钟)。限于篇幅,就不罗嗦了。

    --EOF--


    相关文章|Related Articles

    评论数(5)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter
    本文网址:http://www.dbanotes.net/arch/five-minute_rule.html

    DBA Notes 理念: 用简约的技术取得最大的收益...

    02:21 《把时间当作朋友》海报 » Uploads from 车东@FlickR

    车东@FlickR posted a photo:

    《把时间当作朋友》海报

    粥粥专门为笑来新书做的海报,很有创意哟;
    www.douban.com/subject/3609132/
    利用心智 获得解放


    ^==Back Home: www.chedong.com

    ^==Back Digest Home: www.chedong.com/digest/

    <== 2009-07-01
      七月 2009  
        1 2 3 4 5
    6 7 8 9 10 11 12
    13 14 15 16 17 18 19
    20 21 22 23 24 25 26
    27 28 29 30 31    
    ==> 2009-07-03