分布式存储——强一致性,弱一致性。适合应用场景才是最好的
2014-11-02 23:46
405 查看
Storage systems use one of two different architectural approaches to provide scalability, performance and resiliency: eventual consistency or strong consistency. Object storage systems such as Amazon S3 and Swift are eventually consistent, which provide massive
scalability and ensures high availability to data even during hardware failures. Block storage systems and filesystems are strongly consistent, which is required for databases and other real-time data, but limits their scalability and may reduce availability
to data when hardware failures occur.
A key reason why Swift serves so well for highly-available, unstructured application data is that its design, just like Amazon S3, incorporates eventual consistency. In Swift, objects are protected by storing multiple copies of data so that if one node fails,
the data can be retrieved from another node. Even if multiple nodes fail, data will remain available to the user. Swift’s design for eventual consistency means that there is a guarantee that the system will eventually become consistent and have the most up-to-date
version of data for all copies of the data but still provide availability to data should hardware fail. This design makes it ideal when performance and scalability are critical, particularly for massive, highly distributed infrastructures with lots of unstructured
data serving global sites.
Strong consistency is required when all reads needs to be guaranteed to return the most recent data. With this approach, all nodes in the storage system must be queried to ensure that all updates have been written to all nodes and the read is returning the
most recent copy. While databases with transactions require strong consistency, backup files, log files, and unstructured data do not need that same consistency. Based on this architecture, storage systems with strong consistency are difficult to scale, especially
when it comes to multi-site configurations. This means that as the data grows, becomes more distributed—such as over multiple regions—or when there is a hardware failure, the chance for data not being available in a strongly consistent storage system increases.
By using an eventual consistency design, Swift does not have those drawbacks, which makes it an ideal choice for for highly scalable, distributed storage of unstructured data.
Each of these architectural approaches has its own definition, appropriate use cases, and tradeoffs—all of which need to be understood to appropriately identify which architecture is most appropriate for your data.
scalability and ensures high availability to data even during hardware failures. Block storage systems and filesystems are strongly consistent, which is required for databases and other real-time data, but limits their scalability and may reduce availability
to data when hardware failures occur.
Eventually Consistent Storage Systems | Strongly Consistent Storage Systems |
Amazon S3 OpenStack Swift | Block storage Filesystems |
the data can be retrieved from another node. Even if multiple nodes fail, data will remain available to the user. Swift’s design for eventual consistency means that there is a guarantee that the system will eventually become consistent and have the most up-to-date
version of data for all copies of the data but still provide availability to data should hardware fail. This design makes it ideal when performance and scalability are critical, particularly for massive, highly distributed infrastructures with lots of unstructured
data serving global sites.
Strong consistency is required when all reads needs to be guaranteed to return the most recent data. With this approach, all nodes in the storage system must be queried to ensure that all updates have been written to all nodes and the read is returning the
most recent copy. While databases with transactions require strong consistency, backup files, log files, and unstructured data do not need that same consistency. Based on this architecture, storage systems with strong consistency are difficult to scale, especially
when it comes to multi-site configurations. This means that as the data grows, becomes more distributed—such as over multiple regions—or when there is a hardware failure, the chance for data not being available in a strongly consistent storage system increases.
By using an eventual consistency design, Swift does not have those drawbacks, which makes it an ideal choice for for highly scalable, distributed storage of unstructured data.
Each of these architectural approaches has its own definition, appropriate use cases, and tradeoffs—all of which need to be understood to appropriately identify which architecture is most appropriate for your data.
相关文章推荐
- 选择创业项目的基础——适合自己的才是最好的
- SSCE(SQL Server Compact Edition)适合哪些应用场景
- Python适合自己的IDE才是最好的IDE
- 适合自己的才是最好的
- cardova(Phone GAP)适合应用的场景
- 适合自己的才是最好的
- Vim - 适合自己的,才是最好的
- shell图形化监控网络流量 网络流量的监控工具有很多,如:Mrtg、Cacti、Zabbix等等,他们都有着各自的特点,不同的侧重,只为适合不同的应用场景的各种特殊需求。除了网络流量监控工具以外,还
- Plone-最好的、最适合企业级应用的国外开源CMS系统
- Key/Value之王Memcached初探:三、Memcached解决Session的分布式存储场景的应用
- SSCE(SQL Server Compact Edition)适合哪些应用场景
- IPD vs AD 历史从来不乏各种主义和思想,适合自己的才是最好的!
- SSCE(SQL Server Compact Edition)适合哪些应用场景
- Key/Value之王Memcached初探:三、Memcached解决Session的分布式存储场景的应用
- Redis的七种特性及其适合的应用场景
- 选择创业项目的基础――适合自己的才是最好的
- SSCE(SQL Server Compact Edition)适合哪些应用场景
- 观点:Rails还是PHP?适合才是最好
- 场景应用:小而美,才是未来的营销世界
- Vim - 适合自己的 才是最好的