Mysql

Log and status files
Loading time zone tables
Securing MySQL installation
Upgrading
MySQL Administrator
mysql
mysqladmin
SQL modes
User variables
Prepared statement
Full Text Search
Multi-table UPDATE and DELETE
VIEWS
Importing and Exporting Data
Storage engines (INNODB, MyISAM, MEMORY, NDB)
Table Maintenance
STORED PROCEDURES / FUNCTIONS
Triggers
Transaction
Obtaining metadata
Debugging
Optimizations
Choosing appropriate storage engine
Character Set and Collation
Locking
Backup and Recovery

WHERE vs HAVING
SELECT
SUB-QUERIES
JOINS (SIMPLE JOIN, STANDARD JOIN, INNER JOIN, CROSS JOIN, SELF JOIN, NATURAL JOIN, OUTER JOIN)
UNION / Compound Queries
CREATE DATABASE
ALTER DATABASE
DROP DATABASE

CREATE TABLE
ALTER TABLE
DROP TABLE
RENAME TABLE
TRUNCATE TABLE
CREATE INDEX
DROP INDEX

SHOW
INSERT
REPLACE
UPDATE
DELETE
Purge Binary Log Files
Complex Table Structure Changes
Managing user right and privileges
OLTP vs OLAP
Functions
Comments
misc
mysqlshow
myisamchk -a
mysqladmin
Cardinality
EXPLAIN
sqlUnit

mysql command line
shell scripting
Date/Time functions
Set initial root password
Dump and reload
Interesting SQL
scenarios

http://dev.mysql.com (Reference Manuals)
http://www.mysql.com/certification (all things, including status of your certification)
http://www.mysql.com/certification/studyguides (Study Guide Errata)
http://www.mysql.com/certification/candguide (price)
http://www.vue.com/mysql (page 6 to page 12)
http://www.mysql.com/certification/candidate (special offers, information on pre-release of new certifications)
http://www.mysql.com/certification/results (confirm that your certificate is valid
http://www.mysql.com/training
http://superb-west.dl.sourceforge.net/sourceforge/souptonuts/README_mysql.txt

1. Have an environment that is exactly the same (or at least a representation) of production environment so that you do dry push / release, and get an accurate indication of how long a real release will take.
2. Back-up all databases (at least production database, and development database). There is always a chance that developers might accidentally drop the development database, or delete all entries from tables (unit tests). We since then have setup unit test to use a different username and password, and/or even on a different server / port. Staging databases can be created from a copy of production database.

• Use cache (memcache)
• Monitor and graph everything. Use Nagios and Cacti or something better.
• Capacity planning. Know the limit of your hardware and how much of it you are using.
• Use a CDN. Put static file on a CDN.
• Distribute your data to geographically diverse data centers to handle power failures.
• Consider using virtualized storage/clustered file systems from the start. It allows you to massively parallelize IO access while being able to add disk as needed without any reorganization needed.
• Develop tools that work in a production environment. Can't simulate everything in test environment. (Having a logger)
• Horizontal partitioning
• Move hottest queries / tables into separate clusters.
• Using a primary and slave there's a single point of failure because it's hard to promote a slave to a master. Went to a multi master solution. (Feedburner)
• Profile your code
• Know your DB workload, Cacti really helps with this.
• ‘EXPLAIN’ all of your queries. Helps keep crushing queries out of the system.
• End up with a design that is as minimal as possible. Simplicity is the key if you really want to build large distributed systems. (Amazon)
• To scale you have to partition, so you are left with choosing either high consistency or high availability for a particular system. You must find the right overlap of availability and consistency. (Amazon)
• Choose a specific approach based on the needs of the service. (Amazon)
• You must change your mentality to build really scalable systems. Approach chaos in a probabilistic sense that things will work well. In traditional systems we present a perfect world where nothing goes down and then we build complex algorithms (agreement technologies) on this perfect world. Instead, take it for granted stuff fails, that's reality, embrace it. For example, go more with a fast reboot and fast recover approach. With a decent spread of data and services you might get close to 100%. Create self-healing, self-organizing lights out operations. (Amazon)
• Create a shared nothing infrastructure. Infrastructure can become a shared resource for development and deployment with the same downsides as shared resources in your logic and data tiers. It can cause locking and blocking and dead lock. A service oriented architecture allows the creation of a parallel and isolated development process that scales feature development to match your growth. (Amazon)
• Open up you system with APIs and you'll create an ecosystem around your application. (Amazon)
• Only way to manage as large distributed system is to keep things as simple as possible. Keep things simple by making sure there are no hidden requirements and hidden dependencies in the design. Cut technology to the minimum you need to solve the problem you have. It doesn't help the company to create artificial and unneeded layers of complexity. (Amazon)
• Organizing around services gives agility. You can do things in parallel is because the output is a service. This allows fast time to market. Create an infrastructure that allows services to be built very fast. (Amazon)
• There's bound to be problems with anything that produces hype before real implementation (Amazon)
• Build your own infrastructure for performance, reliability, and cost control reasons. By building it yourself you never have to say you went down because it was company X's fault. Your software may not be more reliable than others, but you can fix, debug, and deployment much quicker than when working with a 3rd party. (Amazon)
• Use measurement and objective debate to separate the good from the bad. I've been to several presentations by ex-Amazoners and this is the aspect of Amazon that strikes me as uniquely different and interesting from other companies. Their deep seated ethic is to expose real customers to a choice and see which one works best and to make decisions based on those tests. (Amazon)
• People's side projects, the one's they follow because they are interested, are often ones where you get the most value and innovation. Never underestimate the power of wandering where you are most interested. (Amazon)
• Involve everyone in making dog food. Go out into the warehouse and pack books during the Christmas rush. That's teamwork. (Amazon)
• Create a staging site where you can run thorough tests before releasing into the wild. (Amazon)
• A robust, clustered, replicated, distributed file system is perfect for read-only data used by the web servers. (Amazon)
• Have a way to rollback if an update doesn't work. Write the tools if necessary. (Amazon)
• Look for three things in interviews: enthusiasm, creativity, competence. The single biggest predictor of success at Amazon.com was enthusiasm. (Amazon)
• Hire a Bob. Someone who knows their stuff, has incredible debugging skills and system knowledge, and most importantly, has the stones to tackle the worst high pressure problems imaginable by just leaping in. (Amazon)
• Innovation can only come from the bottom. Those closest to the problem are in the best position to solve it. any organization that depends on innovation must embrace chaos. Loyalty and obedience are not your tools. (Amazon)
• Creativity must flow from everywhere. (Amazon)
• Everyone must be able to experiment, learn, and iterate. Position, obedience, and tradition should hold no power. For innovation to flourish, measurement must rule. (Amazon)
• Embrace innovation. (Amazon)
• Don't pay for performance. Give good perks and high pay, but keep it flat. Recognize exceptional work in other ways. Merit pay sounds good but is almost impossible to do fairly in large organizations. Use non-monetary awards. It's a way of saying thank you, somebody cared. (Amazon)
• Get big fast. The big guys like Barnes and Nobel are on your tail. Amazon wasn't even the first, second, or even third book store on the web, but their vision and drive won out in the end. (Amazon)
• Prohibit direct database access by clients. This means you can make you service scale and be more reliable without involving your clients. This is much like Google's ability to independently distribute improvements in their stack to the benefit of all applications. (Amazon)
• Create a single unified service-access mechanism. This allows for the easy aggregation of services, decentralized request routing, distributed request tracking, and other advanced infrastructure techniques. (Amazon)
• Making Amazon.com available through a Web services interface to any developer in the world free of charge has also been a major success because it has driven so much innovation that they couldn't have thought of or built on their own. (Amazon)
• Developers themselves know best which tools make them most productive and which tools are right for the job. (Amazon)
• Don't impose too many constraints on engineers. Provide incentives for some things, such as integration with the monitoring system and other infrastructure tools. But for the rest, allow teams to function as independently as possible. (Amazon)
• Developers are like artists; they produce their best work if they have the freedom to do so, but they need good tools. Have many support tools that are of a self-help nature. Support an environment around the service development that never gets in the way of the development itself. (Amazon)
• You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service. (Amazon)
• Developers should spend some time with customer service every two years. Their they'll actually listen to customer service calls, answer customer service e-mails, and really understand the impact of the kinds of things they do as technologists. (Amazon)
• Use a "voice of the customer," which is a realistic story from a customer about some specific part of your site's experience. This helps managers and engineers connect with the fact that we build these technologies for real people. Customer service statistics are an early indicator if you are doing something wrong, or what the real pain points are for your customers. (Amazon)
• Infrastructure for Amazon, like for Google, is a huge competitive advantage. They can build very complex applications out of primitive services that are by themselves relatively simple. They can scale their operation independently, maintain unparalleled system availability, and introduce new services quickly without the need for massive reconfiguration. (Amazon)

http://soa.sys-con.com/node/262024

MapReduce
MapReduce
Google Architecture 2008
GoogleTalk Architecture 2007
Flikr 2007
YouTube Architecture 2008

Friendster Architecture 2005
MySpace Architecture 2009
Amazon Architecture
Feedburner Architecture

MongoDB