Voting is now open for the 2012 election of at large directors of the Drupal Association. Two directors will be elected from among the ten candidates.

About the Drupal Association elections

When we designed a new governance structure for the Drupal Association last year, we decided that most of the board is selected through a nominating committee with the goal to carefully balance many factors like needed skills and geographical and sector representation. However, it was also deemed important that we have directors chosen directly by the Drupal community to make sure that the community is always well-represented.

We're holding our first open community elections! Two community "at large" directors will be elected to the Drupal Association Board of Directors, and YOU can get to say who they are!

Where to find out about candidates

• Review their nomination profiles.
• Read the notes from the two all candidates' meetings at http://groups.drupal.org/node/207398.

Who can vote?

Voting is open to all individuals who registered an account on drupal.org prior to January 18, 2012 and who have logged into that account at least once in the one-year period prior to February 3, 2012.

There is no need to register to vote. The voting system has been set up and prepopulated with the list of eligible voters.

How to vote

• Log in to this site.
• Visit the https://association.drupal.org/2012-vote page. After clicking through, you will be asked to rank each of the eligible voters, from 1st (top choice) to 10th (last choice). You also need to check a box confirming you're an eligible voter. Make your selections and save the form. That's it!

How does voting work?

The voting is done using the "Instant Runoff" voting method, powered by Decisions module. For more about this method of voting, please see this helpful YouTube video which explains it with post-it notes: http://www.youtube.com/watch?v=wA3_t-08Vr0

Can I change my mind after I've voted?

Yes! Before the close of voting, you can return to the voting form, cancel your previous vote, and submit a new vote.

When will voting close?

Tuesday, February 7, 2012 is the last day of voting. Voting will close at 00:00 UTC on Wednesday, February 8, 2012.

How will results be determined and announced?

When voting closes, a four-member elections team will review the results and post them to this site (association.drupal.org). Results will then be forwarded to the Drupal Association board for ratification.

The election team includes Angela Byron, DA board member; Cary Gordon, DA board member; Nedjo Rogers, DA advisory board member; and Thomas Svenson, Drupal community member who participated in the community process of planning the elections.

Why was voting delayed?

We had focused a bit too much on organizing the elections and left finalizing the actual voting system till the last minute. After several community members and Drupal Association staff pitched in, we got the elections system up about 3 hours after the planned opening of voting.

Wait. Only XXX eligible voters? What gives?

Despite the fact that the voting form lists far fewer, there are actually 270K Drupal.org accounts that fit the voter eligibility criteria. Valid accounts are added to the electorate list when they visit the Association website. These shenanigans are due to the Bakery module, our single-sign on solution, and the requirement to reconcile peoples' Association.drupal.org user IDs and their Drupal.org user IDs.

Problems and solutions

If you believe you are eligible to vote and try to vote and cannot or encounter some error, please post an issue to the Drupal Association issue queue, selecting "elections" as the component.

More about the elections

• The nominations announcement.
• The elections plan.
• All elections posts.

Drupal 7.11 and 6.23, maintenance releases which fix security vulnerabilities are now available for download.

Drupal 7.12 and 6.24 also fix other issues reported through the bug tracking system.

Download Drupal 7.12
Download Drupal 6.24

Upgrading your existing Drupal 7 and 6 sites is strongly recommended. There are no new features in these releases. For more information about the Drupal 7.x release series, consult the Drupal 7.0 release announcement, more information on the 6.x releases can be found in the Drupal 6.0 release announcement. Drupal 5 is no longer maintained, upgrading to Drupal 6 is recommended.

Security information

We have a security announcement mailing list, a history of all security advisories, and an RSS feed with the most recent security advisories. We strongly advise Drupal administrators to sign up for the list.

Drupal 7 and 6 include the built-in Update status module, which informs you about important updates to your modules and themes.

Bug reports

Both Drupal 7.x and 6.x branches are being maintained, so given enough bug fixes (not just bug reports) more maintenance releases will be made available, according to our monthly release cycle.

Changelog

Drupal 7.11 only includes fixes for security issues. Drupal 7.12 also includes bugfixes. The full list of changes between the 7.10 and 7.12 releases can be found by reading the 7.12 release notes. A complete list of all bug fixes in the stable 7.x branch can be found in the git commit log.

Drupal 6.23 only includes fixes for security issues. Drupal 6.24 also includes bugfixes. The full list of changes between the 6.22 and 6.24 releases can be found by reading the 6.24 release notes. A complete list of all bug fixes in the stable 6.x branch can be found at git commit log.

Security vulnerabilities

Drupal 7.11 and 6.23 were released in response to the discovery of security vulnerabilities. Details can be found in the official security advisory:

• SA-CORE-2012-001

To fix the security problem, please upgrade Drupal.

What is included with each release?

We made two versions of both Drupal 7 and 6 available, so you can choose to only include security fixes (Drupal 7.11 and 6.23 respectively) or security fixes and bugfixes (Drupal 7.12 and 6.24). You can choose your preferred version. We are trying to make it easier and quicker to roll out security updates by making security-only releases available as well as ones with bugfixes included. We hope this helps you roll out the fixes as soon as possible. Read more details in the handbook.

Update notes

The default.settings.php file was changed in Drupal 7.12, to add documentation about PDO attribute override capabilities that were added as a result of #1309278: Make PDO connection options configurable.

The robots.txt file was changed in Drupal 6.24 to block filter tips from search engines. The .htaccess and (default.)settings.php files were not changed in Drupal 6. Additionally, indexes were added to the node_comment_statistics and comment tables, for performance.

Known issues # Drupal 7

The Drupal 7.11 release is only an incremental release off of Drupal 7.9, instead of 7.10, so it is missing bug fixes introduced in 7.10. Discussion is ongoing at #1430404: Drupal 7.11 is missing all the bug fixes from Drupal 7.10.

Drupal 7.12 is also only compatible with Menu Block 7.x-2.3 and higher, and Internationalization (i18n) 7.x-1.4 and higher.

Drupal 6

In Drupal 6.24, if you have the contributed user_delete module enabled on your site, the update will fail with a Cannot redeclare user_delete_access() error. An update of user_delete module is being worked on.

In Drupal 6.24 if you had locale module enabled earlier, but it is not currently turned on, the update will fail with Call to undefined function locale_inc_callback(). A fix is being worked on for Drupal core.

In Drupal 6.24 if you run your updates with Drush, you might experience duplicate entry errors in your system table. See the ongoing discussion at http://drupal.org/node/1425868

While id Software may have recently lost its main Linux game developer (Timothee Bessett), they haven't abandoned their open-source ways. This afternoon John Carmack had an interesting tweet...

While id Software may have recently lost its main Linux game developer (Timothee Bessett), they haven't abandoned their open-source ways. This afternoon John Carmack had an interesting tweet...

 

Read more at Phoronix

Elections for at large Drupal Association elections are kicking into high gear with two all candidates meetings this week before voting opens Friday.

Election candidates will participate in all candidates meetings are scheduled over the next two days (Wed., Thurs. or Fri., depending on your location). The first meeting, intended to work for people in the Asia and the Pacific, is scheduled for 01:00 UTC on Thursday. That's 5 PM PST on Wednesday for those in the US and Canada.

The second all candidates meeting at 17:00 UTC Thursday is timed for participants in Europe, Africa, and the Americas.

Then on Friday voting will open. Details on voting will be posted to association.drupal.org.

See the elections announcement for more on how to learn about the candidates.

We're proud to present a new design for the Mollom.com website.

We first launched the Mollom.com site in 2007. For more than four years, Mollom.com was using the same design. As we grew Mollom, we wanted to address some of the issues that we've been stewing over since our original design. We have been planning to redesign the site for over a year now but work on the Mollom web service and developing new Mollom products have always had a higher priority so we haven't found the time to complete the new design until now.

The old Mollom.com design that we used from 2007 to early 2012.

The new design is the first step in our plans to reorganize the website. We still have updates to make to the content of some pages, for example. Already, we think the new design is a fresh new change that improves usability.

Take a look at the new mollom.com, we hope you like it!

The new Mollom.com website design.

The more I use AutoKey, the more I believe it to be an essential piece of software for the Linux desktop. If you happened to miss my last article about it, AutoKey is a system-wide service that allows you to easily set scripts to run when certain key combinations are pressed. AutoKey also lets you set text shortcuts for longer words or phrases.

The more I use AutoKey, the more I believe it to be an essential piece of software for the Linux desktop. If you happened to miss my last article about it, AutoKey is a system-wide service that allows you to easily set scripts to run when certain key combinations are pressed. AutoKey also lets you set text shortcuts for longer words or phrases.

Read more at Ostatic

The final session selections for DrupalCon Denver were announced this week. DrupalCon will take place March 19-23, 2012. Get your tickets soon so that you don't miss out on over 100 sessions across 8 tracks! This year we have added tracks specifically for Non-profit, Government & Education, in addition to Community, Commerce, Mobile, Design & User Experience, Business & Strategy, Coding & Development, Site Building, and Core Conversations.

Conference Dates:
March 19 - Pre-conference trainings -- over 16 from beginners to advanced + API Hack-a-thon

March 20 - 22 - Three complete days of 104 sessions starting with Keynotes: Dries Buytaert, Founder of Drupal and Drupal Project lead, Mitchell Baker, chairperson for the Mozilla Foundation, and Luke Wroblewski, digital product leader coming to talk about mobile.

March 22 - Drupal Means Business - included with conference registration to learn how to integrate Drupal into your business.

March 23 - All-day Contribution Sprint -- one of the largest anywhere!

Plus, parties, ski trips, networking, contests and more, all for the $350 conference fee! Thank you to our wonderful sponsors for helping this to remain one of the lowest cost open source conferences around.

Get your ticket to DrupalCon Denver today. What are you waiting for? We want to see you in Denver!

P.S. Conference registration is $350 until February 21 or when tickets are gone! Early registration helps us to plan the conference and keep our costs low by only ordering what is needed. A limited number of 1/2-priced student tickets are still available.

Follow @drupalcon on Twitter or find us on Facebook.

Like at previous DrupalCon's, I'm co-organizing a Core Conversations track at DrupalCon Denver.

The Core Conversations track is a place for people actively working on Drupal or Drupal.org to meet and plan the future of Drupal. Each session is either two 15 minute or one 30 minute presentation, followed by 30 minutes of discussion.

I know a lot of you contribute to Drupal or want to start contributing. If so, Core Conversations are a unique opportunity to present in front of key Drupal contributors, and to make the case for why we need to do more of A or B (e.g. authoring experience improvements, API overhauls, etc.). We need UX conversations, performance conversations, feature conversations, etc. Please share your ideas with the world through Drupal core.

If you have ideas for Drupal core, and you are attending DrupalCon, I suggest that you submit a proposal as soon as possible. The deadline is February 1st so don't wait too long. To get your ideas flowing, here are our conversations from Drupalcon London and Drupal Chicago.

Today Amazon Web Services has launched the AWS Storage Gateway, making the power of secure and reliable cloud storage accessible from customers’ on-premises applications.

We have been working closely with our customers on their requests to bring the power of the Amazon Web Services cloud closer to their existing on-premises compute infrastructures. The Amazon Virtual Private Cloud extends on-premises compute with all the power of AWS, making it elastic, scalable and highly reliable. AWS Identity and Access Management brings together on-premises and cloud identity management. VM Import allows our customers to move virtual machine images from their datacenters to the Cloud and Amazon Direct Connect makes the network latencies and bandwidth between on-premises and AWS more predictable. With the launch of the AWS Storage Gateway our customers can now integrate their on-premises IT environment with AWS’s storage infrastructure.

The AWS Storage Gateway is a service connecting an on-premises software appliance with cloud-based storage. Once the AWS Storage Gateway’s software appliance is installed on a local host, you can mount Storage Gateway volumes to your on-premises application servers as iSCSI devices, enabling a wide variety of systems and applications to make use of them. Data written to these volumes is maintained on your on-premises storage hardware while being asynchronously backed up to AWS, where it is stored in Amazon S3 in the form of Amazon EBS snapshots. Snapshots are encrypted to make sure that customers do not have to worry about encrypting sensitive data themselves. When customers need to retrieve data, they can restore snapshots locally, or create Amazon EBS volumes from snapshots for use with applications running in Amazon EC2.

Here are three example use cases that we envision for the AWS Storage Gateway. The first one is using the AWS Storage Gateway to back up your data to Amazon S3’s highly reliable storage environment. Amazon S3 is designed to sustain the concurrent loss of data in two facilities, redundantly storing your data on multiple devices across multiple facilities in an AWS Region. So, backing up your data to Amazon S3 means a lot less headaches worrying about your local storage environment.

The second use case is where customers want to move data between local infrastructure and the Amazon Web Services cloud to provide access to applications and other computations running in Amazon EC2. The use of the Amazon EBS snapshot format means the data that was on-premises can be restored as an Amazon EBS volume mounted to an Amazon EC2 instance.

The third use case, cloud-based Disaster Recovery, is a specific variation of the previous two. If there is a failure in your local infrastructure, you can quickly launch a DR environment in Amazon EC2 which will have full access to the data snapshots backed up into Amazon S3 by the AWS Storage Gateway.

For more information on the AWS Storage Gateway, you can visit the detail page Jeff Barr over at the AWS Developer Blog has more details.

هناك سبب وجيه لإستحواد متصفح مايكرُسفت على 95% من حصة السوق على حساب نتسكيب (سلف فَيَرفُكس) : إنترنت إكسبلُرر 6 كان يقوم بأشياء لم يكن سابقوه قادرون على القيام بها. كان هناك HTML حركي و CSS ونعم حتى بعض خاصيات الحماية الجديدة .

لكن مع مرور السنوات أظهرت ميزاته الخاصة وجها آخر. قامت كل المواقع الرئيسية بتحسين أدائها على إنترنت إكسبلُرر 6 حتى وصل الأمر إلى عدم عملها بشكل جيّد على متصفحات أخرى.

فل نتقدّم سريعا إلى 2011. متصفح الموضة هو غوغل كروم الذي حسب إحاصائيات StatCounter تجاوزت حصته في السوق المتصفح المفّضل سابقا فَيَرفُكس.كروم قادر على القيام بأشياء تعجز عنها المتصفحات الأخرى، وغوغل لم تعد تعرف سوى كروم أي أن بعض مواقها لا تعمل بشكل كامل إلا به. حتى اليوم يمكنك أن تقرأ على مدونة غوغل بوجود مستوى جديد من لعبة الطيور الغاضبة تعمل فقط على كروم.

الأمر مزعج عند الأخد بعين الإعتبار ما قدمته غوغل لفتح الوِب؛ لم تكن غوغل لتوجد لولا وجود معايير حقيقية مفتوحة على الوِب. لكن أكثر فأكثر أصبح كروم بوابة لخدمات غوغل أدت إلى إقصاء المتصفّحات الأخرى.

طبعا بإمكان أي شخص إنشاء موقع يعمل على كروم إذن فهو مفتوح من هذه الناحية، مفتوح. لكن لو كان هذا الموقع يعمل فقط على كروم ولا يعمل على باقي المتصفحات الرئيسية فهذا إنفتاح غير كامل على النظام الإيكولوجي للوِب. أي شخص يمكن أن ينشئ موقع يعمل بشكل كامل على  إنترنت إكسبلُرر 6، نفس المشكلة : الموقع لن يعمل بشكل كامل على باقي المتصفّحات.

بدأت بالظهور مؤخرا حالات لخدمات غوغل تعمل فقط على كروم ومع إصدار النسخة 15 قامت عملاق البحث على الإنترنت بتغير خاصية بسيطة على الواجهة  — صفحة اللسان الجديد — لتعزيز متجر تطبيقات وِب كروم الذي كان مجرّد موقع يعمل على نفس المتصفح. قبل هذا أعلنت الشركة عن إمكانية إستخدام بريد الوِب Gmail دون إتصال. وخمّنوا ماذا ؟ الميزة تعمل فقط على كروم.

ليس هذا المثال الوحيد على خدمات غوغل التي تعمل على كروم فقط ؛ هناك المزيد مثل : صفحات غوغل الفورية، Google Cloud Print، رفع الملفات والسحب والإفلات على مستندات غوغل وتطبيق غوغل للتنبيه بالبريد و أحداث التقويم.

"معاير" أخر، SPDY، الذي يمكن أن يحول الوِب إلى شبكة غوغل العنكبوتية (Google Wide Web نسبة إلى World Wide Web). ـ SDPDY هو بديل للـ HTTP يقوم بضغط بيانات الترويسة ويسمح بإتصال مستمر بين الخادم والمتصفح. يتّضح إذن أن بعض مواقع غوغل تستعمل فعلا SPDY عند تصفّحها بكروم. كما هو الحال مع الصفحات الفورية، التقنية متاحة للتنفيذ للناشرين على الوِب لكن مرة أخرى غوغل نفسها هي الداعم الوحيد. شيء جيّد، تفاعلات وِب أسرع، لكن دعونا لا ننسى أن وصول الجميع باستخدام أي برنامج كان سبب في إقلاع الوِب.

هذه الإستراتيجية تتبنى على نطاق واسع قواعد اللعبة التي مارستها مايكرُسفت لأجل إنترنت إكسبلُرر 6. عميل الوِب مايكرُسفت أوْتلوك (المثال الرئيسي لموقع على شكل تطبيق يستخدم أجاكس) لا يسمح بإستخدام ميزة البحث داخل علبة البريد إلا بإستخدام إنترنت إكسبلُرر وهو نفس ما بدأت غوغل بفعله : توفير خدمة وِب تعمل تقريبا على جل المتصفّحات لاكنها تتطلب كروم لتعمل بشكل كامل. لحسن الحظ مايكرُسفت تخلّت عن الميزات الخاصة بإنترنت إكسبلُرر نأمل أن تقوم غوغل بنفس الشيء.

في حوار أجريته مؤخرا مع Hakum Lie المدير التقني لمطوري متصفّح أوبرا، أعرب عن قلقه للنهج الذي تتبعه غوغل.

"دائما ما تُطلِق غوغل خدمتها دون إختبارها على كلّ المتصفحات. أحيانا نستيقض صباحا لنجد خدمة جديدة من غوغل مع علل كان من الممكن إصلاحها لو قاموا بالتنسيق معنا خلال مرحلة التطوير" قال Lie. "الأن لديهم متصفّحهم الخاص، سيقل إهتماهم للتأكد أن كل شيء يعمل عند الجميع. وهذا أمر مقلق لأن غوغل لم تكون لتوجد لولا المعايير المفتوحة. ربما كنا جميعا نعيش في أرض مايكرُسفت."

لكن Lie يعترف بمساهمة غوغل في معايير الوِب. "بعض تجاربهم عضيمة"يقول. "إننا في حاجة إلى تجارب مستمرة ولا نتسطيع أن طلب بأن يعمل كل شيء على جميع المتصفحات لكن يجب عليكم الإختبار على المتصفّحات المشهورة."

حتى كروم بوك (Chromebook) أكثر ملكية وإنغلاقا لأنه مجرد متصفح داخل صندوق فارغ. "مشكلتنا مع كروم بوك أنه منصة جدّ مغلقة" يقول Lie. "إشتكينا من مايكرُسفت طوال هذه السنوات، لكن على ويندوز يمكن إنشاء متصّفح منافس."

يمكن قول نفس الشيء على أجهزة آبل بنظام iOS مثل الآيباد.  رغم أن كروم بوك ليس بشهرة الآيباد ففي اليوم الذي ستصبح جميع الحواسيب عبارة عن كروم بوك، إختيار المتصفح وفتح المصدر سيصبحان شيئان من الماضي.

مثل الشركات المتعدّدة الجنسية، غوغل تريد أن تصبح الأولى في كل شيء. سبق ونجحت في مجال البحث على الإنترنت، لا تسيئوا فهمي، غوغل قامت بعمل رائع. كروم ما كان ليصل لهذه الشهرة دون هذا الوضع. إنه إختياري الشخصي كمحرر في PCMag لأنه أسرع من سابقيه وظهوره على الساحة أجبر باقي المتصفّحات أن تتحسّن. أمل فقط أن لا تُأثّر هذه التحسينات على الإنفتاح والتوافقية.

المقال الأصلي (Michael Muchmore ـ 4 دجنبر 2011 ـ PCMag ـ) : http://ur1.ca/6aqve
الترجمة الفرنسية : http://ur1.ca/6f10a
- من وجهة نظري، المقالة ليست إنتقاد لغوغل كشركة في حد ذاتها، إنما هي نظرة على سوء تعاملها مع تقنية ووضع معيّن. -
مرحّب بإقتراحاتكم لتحسين الترجمة

Today is a very exciting day as we release Amazon DynamoDB, a fast, highly reliable and cost-effective NoSQL database service designed for internet scale applications. DynamoDB is the result of 15 years of learning in the areas of large scale non-relational databases and cloud services. Several years ago we published a paper on the details of Amazon’s Dynamo technology, which was one of the first non-relational databases developed at Amazon. The original Dynamo design was based on a core set of strong distributed systems principles resulting in an ultra-scalable and highly reliable database system. Amazon DynamoDB, which is a new service, continues to build on these principles, and also builds on our years of experience with running non-relational databases and cloud services, such as Amazon SimpleDB and Amazon S3, at scale. It is very gratifying to see all of our learning and experience become available to our customers in the form of an easy-to-use managed service.

Amazon DynamoDB is a fully managed NoSQL database service that provides fast performance at any scale. Today’s web-based applications often encounter database scaling challenges when faced with growth in users, traffic, and data. With Amazon DynamoDB, developers scaling cloud-based applications can start small with just the capacity they need and then increase the request capacity of a given table as their app grows in popularity. Their tables can also grow without limits as their users store increasing amounts of data. Behind the scenes, Amazon DynamoDB automatically spreads the data and traffic for a table over a sufficient number of servers to meet the request capacity specified by the customer. Amazon DynamoDB offers low, predictable latencies at any scale. Customers can typically achieve average service-side in the single-digit milliseconds. Amazon DynamoDB stores data on Solid State Drives (SSDs) and replicates it synchronously across multiple AWS Availability Zones in an AWS Region to provide built-in high availability and data durability.

History of NoSQL at Amazon – Dynamo

The Amazon.com ecommerce platform consists of hundreds of decoupled services developed and managed in a decentralized fashion. Each service encapsulates its own data and presents a hardened API for others to use. Most importantly, direct database access to the data from outside its respective service is not allowed. This architectural pattern was a response to the scaling challenges that had challenged Amazon.com through its first 5 years, when direct database access was one of the major bottlenecks in scaling and operating the business. While a service-oriented architecture addressed the problems of a centralized database architecture, each service was still using traditional data management systems. The growth of Amazon’s business meant that many of these services needed more scalable database solutions.

In response, we began to develop a collection of storage and database technologies to address the demanding scalability and reliability requirements of the Amazon.com ecommerce platform. We had been pushing the scalability of commercially available technologies to their limits and finally reached a point where these third party technologies could no longer be used without significant risk. This was not our technology vendors’ fault; Amazon's scaling needs were beyond the specs for their technologies and we were using them in ways that most of their customers were not. A number of outages at the height of the 2004 holiday shopping season can be traced back to scaling commercial technologies beyond their boundaries.

Dynamo was born out of our need for a highly reliable, ultra-scalable key/value database. This non-relational, or NoSQL, database was targeted at use cases that were core to the Amazon ecommerce operation, such as the shopping cart and session service. Any downtime or performance degradation in these services has an immediate financial impact and their fault-tolerance and performance requirements for their data systems are very strict. These services also require the ability to scale infrastructure incrementally to accommodate growth in request rates or dataset sizes. Another important requirement for Dynamo was predictability. This is not just predictability of median performance and latency, but also at the end of the distribution (the 99.9th percentile), so we could provide acceptable performance for virtually every customer.

To achieve all of these goals, we needed to do groundbreaking work. After the successful launch of the first Dynamo system, we documented our experiences in a paper so others could benefit from them. Since then, several Dynamo clones have been built and the Dynamo paper has been the basis for several other types of distributed databases. This demonstrates that Amazon is not the only company than needs better tools to meet their database needs.

Lessons learned from Amazon's Dynamo

Dynamo has been in use by a number of core services in the ecommerce platform, and their engineers have been very satisfied by its performance and incremental scalability. However, we never saw much adoption beyond these core services. This was remarkable because although Dynamo was originally built to serve the needs of the shopping cart, its design and implementation were much broader and based on input from many other service architects. As we spoke to many senior engineers and service owners, we saw a clear pattern start to emerge in their explanations of why they didn't adopt Dynamo more broadly: while Dynamo gave them a system that met their reliability, performance, and scalability needs, it did nothing to reduce the operational complexity of running large database systems. Since they were responsible for running their own Dynamo installations, they had to become experts on the various components running in multiple data centers. Also, they needed to make complex tradeoff decisions between consistency, performance, and reliability. This operational complexity was a barrier that kept them from adopting Dynamo.

During this period, several other systems appeared in the Amazon ecosystem that did meet their requirements for simplified operational complexity, notably Amazon S3 and Amazon SimpleDB. These were built as managed web services that eliminated the operational complexity of managing systems while still providing extremely high durability. Amazon engineers preferred to use these services instead of managing their own databases like Dynamo, even though Dynamo's functionality was better aligned with their applications’ needs.

With Dynamo we had taken great care to build a system that met the requirements of our engineers. After evaluations, it was often obvious that Dynamo was ideal for many database use cases. But ... we learned that engineers found the prospect of running a large software system daunting and instead looked for less ideal design alternatives that freed them from the burden of managing databases and allowed them to focus on their applications.

It became obvious that developers strongly preferred simplicity to fine-grained control as they voted "with their feet" and adopted cloud-based AWS solutions, like Amazon S3 and Amazon SimpleDB, over Dynamo. Dynamo might have been the best technology in the world at the time but it was still software you had to run yourself. And nobody wanted to learn how to do that if they didn’t have to. Ultimately, developers wanted a service.

History of NoSQL at Amazon - SimpleDB

One of the cloud services Amazon developers preferred for their database needs was Amazon SimpleDB. In the 5 years that SimpleDB has been operational, we have learned a lot from its customers.

First and foremost, we have learned that a database service that takes away the operational headache of managing distributed systems is extremely powerful. Customers like SimpleDB’s table interface and its flexible data model. Not having to update their schemas when their systems evolve makes life much easier. However, they most appreciate the fact that SimpleDB just works. It provides multi-data center replication, high availability, and offers rock-solid durability. And yet customers never need to worry about setting up, configuring, or patching their database.

Second, most database workloads do not require the complex query and transaction capabilities of a full-blown relational database. A database service that only presents a table interface with a restricted query set is a very important building block for many developers.

While SimpleDB has been successful and powers the applications of many customers, it has some limitations that customers have consistently asked us to address.

Domain scaling limitations. SimpleDB requires customers to manage their datasets in containers called Domains, which have a finite capacity in terms of storage (10 GB) and request throughput. Although many customers worked around SimpleDB’s scaling limitations by partitioning their workloads over many Domains, this side of SimpleDB is certainly not simple. It also fails to meet the requirement of incremental scalability, something that is critical to many customers looking to adopt a NoSQL solution.

Predictability of Performance. SimpleDB, in keeping with its goal to be simple, indexes all attributes for each item stored in a domain. While this simplifies the customer experience on schema design and provides query flexibility, it has a negative impact on the predictability of performance. For example, every database write needs to update not just the basic record, but also all attribute indices (regardless of whether the customer is using all the indices for querying). Similarly, since the Domain maintains a large number of indices, its working set does not always fit in memory. This impacts the predictability of a Domain’s read latency, particularly as dataset sizes grow.
Consistency. SimpleDB’s original implementation had taken the "eventually consistent" approach to the extreme and presented customers with consistency windows that were up to a second in duration. This meant the system was not intuitive to use and developers used to a more traditional database solution had trouble adapting to it. The SimpleDB team eventually addressed this issue by enabling customers to specify whether a given read operation should be strongly or eventually consistent.

Pricing complexity. SimpleDB introduced a very fine-grained pricing dimension called “Machine Hours.” Although most customers have eventually learned how to predict their costs, it was not really transparent or simple.

Introducing DynamoDB

As we thought about how to address the limitations of SimpleDB and provide 1) the most scalable NoSQL solution available and 2) predictable high performance, we realized our goals could not be met with the SimpleDB APIs. Some SimpleDB operations require that all data for a Domain is on a single server, which prevents us from providing the seamless scalability our customers are demanding. In addition, SimpleDB APIs assume all item attributes are automatically indexed, which limits performance.

We concluded that an ideal solution would combine the best parts of the original Dynamo design (incremental scalability, predictable high performance) with the best parts of SimpleDB (ease of administration of a cloud service, consistency, and a table-based data model that is richer than a pure key-value store). These architectural discussions culminated in Amazon DynamoDB, a new NoSQL service that we are excited to release today.

Amazon DynamoDB is based on the principles of Dynamo, a progenitor of NoSQL, and brings the power of the cloud to the NoSQL database world. It offers customers high-availability, reliability, and incremental scalability, with no limits on dataset size or request throughput for a given table. And it is fast – it runs on the latest in solid-state drive (SSD) technology and incorporates numerous other optimizations to deliver low latency at any scale.

Amazon DynamoDB is the result of everything we’ve learned from building large-scale, non-relational databases for Amazon.com and building highly scalable and reliable cloud computing services at AWS. Amazon DynamoDB is a NoSQL database service that offers the following benefits:

• Managed. DynamoDB frees developers from the headaches of provisioning hardware and software, setting up and configuring a distributed database cluster, and managing ongoing cluster operations. It handles all the complexities of scaling and partitions and re-partitions your data over more machine resources to meet your I/O performance requirements. It also automatically replicates your data across multiple Availability Zones (and automatically re-replicates in the case of disk or node failures) to meet stringent availability and durability requirements. From our experience of running Amazon.com, we know that manageability is a critical requirement. We have seen many job postings from companies using NoSQL products that are looking for NoSQL database engineers to help scale their installations. We know from our Amazon experiences that once these clusters start growing, managing them becomes the same nightmare that running large RDBMS installations was. Because Amazon DynamoDB is a managed service, you won’t need to hire experts to manage your NoSQL installation—your developers can do it themselves.

• Scalable. Amazon DynamoDB is designed to scale the resources dedicated to a table to hundreds or even thousands of servers spread over multiple Availability Zones to meet your storage and throughput requirements. There are no pre-defined limits to the amount of data each table can store. Developers can store and retrieve any amount of data and DynamoDB will spread the data across more servers as the amount of data stored in your table grows.

• Fast. Amazon DynamoDB provides high throughput at very low latency. It is also built on Solid State Drives to help optimize for high performance even at high scale. Moreover, by not indexing all attributes, the cost of read and write operations is low as write operations involve updating only the primary key index thereby reducing the latency of both read and write operations. An application running in EC2 will typically see average service-side latencies in the single-digit millisecond range for a 1KB object. Most importantly, DynamoDB latencies are predictable. Even as datasets grow, latencies remain stable due to the distributed nature of DynamoDB's data placement and request routing algorithms.

• Durable and Highly Available. Amazon DynamoDB replicates its data over at least 3 different data centers so that the system can continue to operate and serve data even under complex failure scenarios.

• Flexible. Amazon DynamoDB is an extremely flexible system that does not force its users into a particular data model or a particular consistency model. DynamoDB tables do not have a fixed schema but instead allow each data item to have any number of attributes, including multi-valued attributes. Developers can optionally use stronger consistency models when accessing the database, trading off some performance and availability for a simpler model. They can also take advantage of the atomic increment/decrement functionality of DynamoDB for counters.

• Low cost. Amazon DynamoDB’s pricing is simple and predictable: Storage is $1 per GB per month. Requests are priced based on how much capacity is reserved: $0.01 per hour for every 10 units of Write Capacity and $0.01 per hour for every 50 units of Read Capacity. A unit of Read (or Write) Capacity equals one read (or write) per second of capacity for items up to 1KB in size. If you use eventually consistent reads, you can achieve twice as many reads per second for a given amount of Read Capacity. Larger items will require additional throughput capacity.

In the current release, customers will have the choice of using two types of keys for primary index querying: Simple Hash Keys and Composite Hash Key / Range Keys:

Simple Hash Key gives DynamoDB the Distributed Hash Table abstraction. The key is hashed over the different partitions to optimize workload distribution. For more background on this please read the original Dynamo paper.

Composite Hash Key with Range Key allows the developer to create a primary key that is the composite of two attributes, a “hash attribute” and a “range attribute.” When querying against a composite key, the hash attribute needs to be uniquely matched but a range operation can be specified for the range attribute: e.g. all orders from Werner in the past 24 hours, all log entries from server 16 with clients IP addresses on subnet 192.168.1.0

Performance Predictability in DynamoDB

In addition to taking the best ideas of Dynamo and SimpleDB, we have added new functionality to provide even greater performance predictability.

Cloud-based systems have invented solutions to ensure fairness and present their customers with uniform performance, so that no burst load from any customer should adversely impact others. This is a great approach and makes for many happy customers, but often does not give a single customer the ability to ask for higher throughput if they need it.

As satisfied as engineers can be with the simplicity of cloud-based solutions, they would love to specify the request throughput they need and let the system reconfigure itself to meet their requirements. Without this ability, engineers often have to carefully manage caching systems to ensure they can achieve low-latency and predictable performance as their workloads scale. This introduces complexity that takes away some of the simplicity of using cloud-based solutions.

The number of applications that need this type of performance predictability is increasing: online gaming, social graphs applications, online advertising, and real-time analytics to name a few. AWS customers are building increasingly sophisticated applications that could benefit from a database that can give them fast, predictable performance that exactly matches their needs.

Amazon DynamoDB’s answer to this problem is “Provisioned Throughput.” Customers can now specify the request throughput capacity they require for a given table. Behind the scenes, DynamoDB will allocate sufficient resources to the table to predictably achieve this throughput with low-latency performance. Throughput reservations are elastic, so customers can increase or decrease the throughput capacity of a table on-demand using the AWS Management Console or the DynamoDB APIs. CloudWatch metrics enable customers to make informed decisions about the right amount of throughput to dedicate to a particular table. Customers using the service tell us that it enables them to achieve the appropriate amount of control over scaling and performance while maintaining simplicity. Rather than adding server infrastructure and re-partitioning their data, they simply change a value in the management console and DynamoDB takes care of the rest.

Summary

Amazon DynamoDB is designed to maintain predictably high performance and to be highly cost efficient for workloads of any scale, from the smallest to the largest internet-scale applications. You can get started with Amazon DynamoDB using a free tier that enables 40 million of requests per month free of charge. Additional request capacity is priced at cost-efficiently hourly rates as low as $.01 per hour for 10 units of Write Capacity or 50 strongly consistent units of Read Capacity (if you use eventually consistent reads you can get twice the throughput at the same cost, or the same read throughput at half the cost) Also, replicated solid state disk (SSD) storage is $1 per GB per month. Our low request pricing is designed to meet the needs of typical database workloads that perform large numbers of reads and writes against every GB of data stored.

To learn more about Amazon DynamoDB its functionality, APIs, use cases, and service pricing, please visit the detail page at aws.amazon.com/DynamoDB and also the Developer Guide. I am excited to see the years of experience with systems such as Amazon Dynamo result in an innovative database service that can be broadly used by all our customers.

Join me at 9AM PST on Wednesday January 18, 2012 to find out what is next in the AWS Cloud. Registration required.