6.4 ARCHITECTURAL CHOICESAnalytical

6.4 ARCHITECTURAL CHOICES
Analytical environments are deployed in different architectural models. Even on parallel platforms, many databases are built on a sharedeverything approach in which the persistent storage and memory components are all shared by the different processing units. A shared-disk approach may have isolated processors, each with its own memory, but the persistent storage on disk is still shared across the system.
These types of architectures are layered on top of SMP machines. While there may be applications that are suited to this approach, there are bottlenecks that exist because of the sharing, because all I/O and memory requests are transferred (and satisfied) over the same bus. As more processors are added, the synchronization and communication needs increase exponentially, and therefore the bus is less able to handle the increased need for bandwidth. This means that unless the need for bandwidth is satisfied, there will be limits to the degree of scalability.
In contrast, in a shared-nothing approach, each processor has its own dedicated disk storage. This approach, which maps nicely to an MPP architecture, is not only more suitable to discrete allocation and distribution of the data, it enables more effective parallelization, and consequently does not introduce the same kind of bus bottlenecks from which the SMP/shared-memory and shared-disk approaches suffer.



6.5 CONSIDERING PERFORMANCE CHARACTERISTICS (55)
When it comes to big data, both the software and the hardware approaches are appealing to the nascent large-scale data analysts. However, there may be contrary perceptions of the benefits of selecting one of these approaches over the other, and Table 6.2 looks at how each supports some of the desired characteristics listed earlier in this book.

6.6 ROW- VERSUS COLUMN-ORIENTED DATA LAYOUTS AND APPLICATION PERFORMANCE
Awareness of the different latency costs associated with the different levels of the memory hierarchy inform the different ways that data can be stored and shared, especially because the alignment and orientation of data on disk can significantly impact the performance of analytical applications. Most traditional database systems employ a row-oriented layout, in which all the values associated with a specific row are laid out consecutively in memory. That layout may work well for transaction processing applications that focus on updating specific records associated with a limited number of transactions (or transaction steps) at a time.
On the other hand, big data analytics applications scan, aggregate, and summarize over massive datasets. These are manifested as algorithmic scans of are performed using multiway joins; accessing whole rows at a time when only the values of a smaller set of columns are needed may flood the network with extraneous data that is not immediately needed and ultimately will increase the execution time.
In other words, analytical applications and queries will only need to access the data elements needed to satisfy join conditions. With roworiented layouts, the entire record must be read in order to access the required attributes, with significantly more data read than is needed to satisfy the request. Also, the row-oriented layout is often misaligned with the characteristics of the different types of memory systems (core, cache, disk, etc.), leading to increased access latencies. Subsequently, row-oriented data layouts will not enable the types of joins or aggregations typical of analytic queries to execute with the anticipated level of performance (Figure 6.1).
That is why a number of software appliances for big data use a database management system that uses an alternate, columnar layout for data that can help to reduce the negative performance impacts of data latency that plague databases with a row-oriented data layout. The values for each column can be stored separately, and because of this, for any query, the system is able to selectively access the specific



column values requested to evaluate the join conditions. Instead of requiring separate indexes to tune queries, the data values themselves within each column form the index. This speeds up data access while reducing the overall database footprint, while dramatically improving query performance (Figure 6.2).
The simplicity of the columnar approach provides many benefits, especially for those seeking a high-performance environment to meet the growing needs of extremely large analytic datasets, as can be seen by the example facets of performance discussed in Table 6.3.

6.7 CONSIDERING PLATFORM ALTERNATIVES
When considering the different ways of deploying an analytics environment, the key decisions for investing in infrastructure focus on how the platform best meets the expected performance needs. One must be willing to specify key measures for system performance to properly assess scalability requirements for the intended analytical applications to help select a specific architectural approach.
The benefits of using hardware appliances for big data center on engineering and integration. They are engineered for high-performance reporting and analytics, yet have a flexible architecture allowing integrated components to be configured to meet specific application needs.


(tr58)
And while there is a capital investment in machinery, hardware appliances are low cost when compared to massive data warehouse hardware systems.
One benefit of using software appliances, meanwhile, is that they can take advantage of low-cost commodity hardware components. In addition, the reliance on commodity hardware allows a software appliance to be elastic and extensible.
However, you must consider all aspects of the performance needs of the different types of applications: data scalability, user scalability, access and loading speed, the need for workload isolation, reliance on parallelization and optimization, reliability in the presence of failures, the dependence on storage duplication or data distribution and replication, among other performance expectations. Then examine how the performance needs of the different types of applications are addressed by each of the architectures. This will provide a measurable methodology for assessing technology suitability.

6.8 THOUGHT EXERCISES
Given the premise of approaches to appliance architectures, here are some questions and exercises to ponder:
• For the three most typical big data application types, describe your expectations for data storage needs, what type of appliance is best, and what are the data management needs?
• Develop a scoring scale between 1 and 5 (where 1 represents a low need and 5 represents a great need) for each of the variables considered for storage requirements (extensibility, accessibility, fault tolerance, I/O speed, integratability). Rate your three applications using your defined scale.
• What are the variables you would consider for assessing the comparable costs and benefits of a software appliance versus a hardware appliance?

Kết quả (Việt) 1:

6.4 SỰ LỰA CHỌN KIẾN TRÚCPhân tích môi trường đã được triển khai trong mô hình kiến trúc khác nhau. Ngay cả trên nền tảng song song, nhiều cơ sở dữ liệu được xây dựng trên một cách tiếp cận sharedeverything trong đó các thành phần liên tục lưu trữ và bộ nhớ được tất cả được chia sẻ bởi các đơn vị xử lý khác nhau. Một cách tiếp cận chia sẻ đĩa có thể đã cô lập bộ vi xử lý, mỗi với bộ nhớ của riêng của nó, nhưng lưu trữ liên tục trên đĩa vẫn còn được chia sẻ trên hệ thống.Các loại kiến trúc lớp trên đầu trang của SMP máy. Trong khi có thể có ứng dụng đó phù hợp với cách tiếp cận này, không có tắc nghẽn tồn tại vì các chia sẻ, bởi vì tất cả các yêu cầu I/O và bộ nhớ được chuyển (và hài lòng) trên xe buýt cùng. Khi thêm bộ vi xử lý được bổ sung, đồng bộ hóa và truyền thông nhu cầu tăng theo cấp số nhân, và do đó xe buýt là ít có khả năng xử lý nhu cầu tăng cho băng thông. Điều này có nghĩa rằng trừ khi cần thiết cho băng thông là hài lòng, sẽ có giới hạn cho mức độ khả năng mở rộng.Ngược lại, trong một cách tiếp cận chia sẻ-không có gì, mỗi bộ vi xử lý đã lưu trữ chuyên dụng đĩa riêng của mình. Cách tiếp cận này, bản đồ độc đáo với một kiến trúc MPP, là không chỉ phù hợp hơn để rời rạc phân bổ và phân phối dữ liệu, nó cho phép hiệu quả hơn parallelization, và do đó không giới thiệu các loại tương tự của tắc nghẽn xe buýt từ đó phương pháp tiếp cận SMP/chia sẻ-bộ nhớ và chia sẻ đĩa bị.6.5 CONSIDERING PERFORMANCE CHARACTERISTICS (55)When it comes to big data, both the software and the hardware approaches are appealing to the nascent large-scale data analysts. However, there may be contrary perceptions of the benefits of selecting one of these approaches over the other, and Table 6.2 looks at how each supports some of the desired characteristics listed earlier in this book.6.6 ROW- VERSUS COLUMN-ORIENTED DATA LAYOUTS AND APPLICATION PERFORMANCEAwareness of the different latency costs associated with the different levels of the memory hierarchy inform the different ways that data can be stored and shared, especially because the alignment and orientation of data on disk can significantly impact the performance of analytical applications. Most traditional database systems employ a row-oriented layout, in which all the values associated with a specific row are laid out consecutively in memory. That layout may work well for transaction processing applications that focus on updating specific records associated with a limited number of transactions (or transaction steps) at a time. On the other hand, big data analytics applications scan, aggregate, and summarize over massive datasets. These are manifested as algorithmic scans of are performed using multiway joins; accessing whole rows at a time when only the values of a smaller set of columns are needed may flood the network with extraneous data that is not immediately needed and ultimately will increase the execution time.In other words, analytical applications and queries will only need to access the data elements needed to satisfy join conditions. With roworiented layouts, the entire record must be read in order to access the required attributes, with significantly more data read than is needed to satisfy the request. Also, the row-oriented layout is often misaligned with the characteristics of the different types of memory systems (core, cache, disk, etc.), leading to increased access latencies. Subsequently, row-oriented data layouts will not enable the types of joins or aggregations typical of analytic queries to execute with the anticipated level of performance (Figure 6.1).
That is why a number of software appliances for big data use a database management system that uses an alternate, columnar layout for data that can help to reduce the negative performance impacts of data latency that plague databases with a row-oriented data layout. The values for each column can be stored separately, and because of this, for any query, the system is able to selectively access the specific



column values requested to evaluate the join conditions. Instead of requiring separate indexes to tune queries, the data values themselves within each column form the index. This speeds up data access while reducing the overall database footprint, while dramatically improving query performance (Figure 6.2).
The simplicity of the columnar approach provides many benefits, especially for those seeking a high-performance environment to meet the growing needs of extremely large analytic datasets, as can be seen by the example facets of performance discussed in Table 6.3.

6.7 CONSIDERING PLATFORM ALTERNATIVES
When considering the different ways of deploying an analytics environment, the key decisions for investing in infrastructure focus on how the platform best meets the expected performance needs. One must be willing to specify key measures for system performance to properly assess scalability requirements for the intended analytical applications to help select a specific architectural approach.
The benefits of using hardware appliances for big data center on engineering and integration. They are engineered for high-performance reporting and analytics, yet have a flexible architecture allowing integrated components to be configured to meet specific application needs.


(tr58)
And while there is a capital investment in machinery, hardware appliances are low cost when compared to massive data warehouse hardware systems.
One benefit of using software appliances, meanwhile, is that they can take advantage of low-cost commodity hardware components. In addition, the reliance on commodity hardware allows a software appliance to be elastic and extensible.
However, you must consider all aspects of the performance needs of the different types of applications: data scalability, user scalability, access and loading speed, the need for workload isolation, reliance on parallelization and optimization, reliability in the presence of failures, the dependence on storage duplication or data distribution and replication, among other performance expectations. Then examine how the performance needs of the different types of applications are addressed by each of the architectures. This will provide a measurable methodology for assessing technology suitability.

6.8 THOUGHT EXERCISES
Given the premise of approaches to appliance architectures, here are some questions and exercises to ponder:
• For the three most typical big data application types, describe your expectations for data storage needs, what type of appliance is best, and what are the data management needs?
• Develop a scoring scale between 1 and 5 (where 1 represents a low need and 5 represents a great need) for each of the variables considered for storage requirements (extensibility, accessibility, fault tolerance, I/O speed, integratability). Rate your three applications using your defined scale.
• What are the variables you would consider for assessing the comparable costs and benefits of a software appliance versus a hardware appliance?

Kết quả (Việt) 2:

6.4 LỰA CHỌN KIẾN TRÚC
môi trường phân tích được triển khai trong các mô hình kiến trúc khác nhau. Ngay cả trên các nền tảng song song, nhiều cơ sở dữ liệu được xây dựng trên một phương pháp tiếp cận sharedeverything trong đó lưu trữ và bộ nhớ các thành phần liên tục được tất cả các chia sẻ của các đơn vị chế biến khác nhau. Một cách tiếp cận chia sẻ đĩa có thể có bộ vi xử lý riêng biệt, mỗi bộ nhớ riêng của mình, nhưng lưu trữ liên tục trên đĩa vẫn còn chia sẻ trên toàn hệ thống.
Những loại kiến trúc được xếp lớp trên cùng của máy SMP. Trong khi có thể có các ứng dụng phù hợp với các phương pháp này, có những vướng mắc tồn tại bởi vì những chia sẻ, bởi vì tất cả các I / O và bộ nhớ yêu cầu được chuyển giao (và thỏa mãn) trên cùng một xe buýt. Khi xử lý nhiều hơn được thêm vào, nhu cầu đồng bộ hóa và truyền thông tăng theo cấp số nhân, và do đó xe buýt là ít có khả năng xử lý các nhu cầu gia tăng về băng thông. Điều này có nghĩa rằng trừ khi nhu cầu băng thông được thỏa mãn, sẽ có giới hạn về mức độ khả năng mở rộng.
Ngược lại, trong một phương pháp chia sẻ gì cả, mỗi bộ xử lý có đĩa lưu trữ chuyên dụng của riêng mình. Cách tiếp cận này, mà bản đồ độc đáo cho một kiến trúc MPP, không chỉ phù hợp hơn để phân bổ và phân phối các dữ liệu rời rạc, nó cho phép song song hiệu quả hơn, và do đó không đưa ra cùng một loại tắc nghẽn xe buýt từ đó SMP / chia sẻ bộ nhớ và các phương pháp chia sẻ đĩa bị. 6,5 XÉT ĐẶC HIỆU (55) Khi nói đến dữ liệu lớn, cả phần mềm và các giải pháp phần cứng được hấp dẫn cho các quy mô lớn các nhà phân tích dữ liệu mới ra đời. Tuy nhiên, có thể có những nhận thức trái ngược về lợi ích của việc lựa chọn một trong các phương pháp tiếp cận trong khác, và Bảng 6.2 trông như thế nào mỗi hỗ trợ một số các đặc tính mong muốn được liệt kê trước đó trong cuốn sách này. 6.6 row- SO VỚI CỘT ĐỊNH HƯỚNG bố trí DỮ LIỆU VÀ ỨNG DỤNG THI Nhận thức về chi phí độ trễ khác nhau kết hợp với các cấp độ khác nhau của các hệ thống phân cấp bộ nhớ thông báo cho các cách khác nhau mà dữ liệu có thể được lưu trữ và chia sẻ, đặc biệt là bởi vì các liên kết và định hướng của dữ liệu trên đĩa có thể tác động đáng kể hiệu suất của các ứng dụng phân tích. Hầu hết các hệ thống cơ sở dữ liệu truyền thống sử dụng một bố trí hàng theo định hướng, trong đó tất cả các giá trị liên quan đến một hàng cụ thể được đặt ra liên tiếp trong bộ nhớ. Bố trí đó có thể làm việc tốt cho các ứng dụng xử lý giao dịch tập trung vào việc cập nhật hồ sơ cụ thể liên kết với một số lượng hạn chế các giao dịch (hoặc các bước giao dịch) tại một thời điểm. Mặt khác, các ứng dụng phân tích dữ liệu lớn quét, tổng hợp, và tóm tắt trên dữ liệu khổng lồ. Đây là những biểu hiện như quét thuật toán của được thực hiện bằng Multiway tham gia; truy cập vào toàn bộ hàng tại một thời điểm khi chỉ có các giá trị của một tập hợp nhỏ của các cột cần thiết có thể làm ngập mạng với dữ liệu không liên quan mà không phải là ngay lập tức cần thiết và cuối cùng sẽ làm tăng thời gian thực hiện. Nói cách khác, các ứng dụng phân tích và truy vấn sẽ chỉ cần truy cập vào các yếu tố dữ liệu cần thiết để đáp ứng điều kiện tham gia. Với bố cục roworiented, toàn bộ hồ sơ phải được đọc theo thứ tự để truy cập các thuộc tính cần thiết, với hơn đáng kể dữ liệu đọc hơn là cần thiết để đáp ứng các yêu cầu. Ngoài ra, việc bố trí hàng theo định hướng thường lệch với các đặc tính của các loại khác nhau của hệ thống bộ nhớ (lõi, bộ nhớ cache, đĩa, vv), dẫn đến tăng độ trễ truy cập. Sau đó, hàng theo định hướng bố trí dữ liệu sẽ không cho phép các loại tham gia hoặc tập hợp điển hình của truy vấn phân tích để thực hiện với mức dự kiến thực hiện (Hình 6.1). Đó là lý do tại sao một số thiết bị phần mềm cho dữ liệu lớn sử dụng một hệ thống quản lý cơ sở dữ liệu sử dụng người thay thế, bố trí cột cho dữ liệu có thể giúp làm giảm các tác động hiệu tiêu cực của độ trễ dữ liệu mà bệnh dịch hạch cơ sở dữ liệu với một bố trí dữ liệu hàng theo định hướng. Các giá trị cho mỗi cột có thể được lưu giữ riêng, và vì điều này, đối với bất kỳ truy vấn, hệ thống có thể truy cập một cách chọn lọc các cụ giá trị cột yêu cầu để đánh giá các điều kiện tham gia. Thay vì yêu cầu chỉ số riêng biệt để chỉnh các truy vấn, dữ liệu giá trị bản thân trong mỗi cột tạo thành các chỉ số. Điều này tăng tốc độ truy cập dữ liệu trong khi giảm các dấu chân cơ sở dữ liệu tổng thể, đồng thời cải thiện đáng kể hiệu suất truy vấn (Hình 6.2). Sự đơn giản của phương pháp tiếp cận cột cung cấp nhiều lợi ích, đặc biệt là cho những người tìm kiếm một môi trường hiệu suất cao để đáp ứng nhu cầu ngày càng tăng của phân tích rất lớn bộ dữ liệu, như có thể được nhìn thấy bởi các khía cạnh ví dụ về hiệu năng thảo luận trong Bảng 6.3. 6.7 XÉT PHƯƠNG ÁN PLATFORM Khi xem xét những cách khác nhau của việc triển khai một môi trường phân tích, các quyết định quan trọng cho đầu tư cơ sở hạ tầng tập trung vào cách thức nền tảng tốt nhất đáp ứng nhu cầu thực hiện dự kiến . Người ta phải sẵn sàng để xác định các biện pháp quan trọng cho hiệu năng hệ thống để đánh giá đúng yêu cầu khả năng mở rộng cho các ứng dụng phân tích nhằm giúp chọn một cách tiếp cận kiến trúc cụ thể. Những lợi ích của việc sử dụng các thiết bị phần cứng cho các trung tâm dữ liệu lớn về kỹ thuật và hội nhập. Chúng được thiết kế để báo cáo hiệu suất cao và phân tích, chưa có một kiến trúc linh hoạt cho phép các thành phần tích hợp phải được cấu hình để đáp ứng nhu cầu ứng dụng cụ thể. (tr58) Và trong khi có một nguồn vốn đầu tư vào máy móc, thiết bị phần cứng là chi phí thấp khi so sánh với đồ sộ các hệ thống phần cứng kho dữ liệu. Một lợi ích của việc sử dụng các thiết bị phần mềm, trong khi đó, họ có thể tận dụng lợi thế của các thành phần phần cứng hàng hóa với chi phí thấp. Ngoài ra, sự phụ thuộc vào phần cứng hàng hóa cho phép một thiết bị phần mềm để được đàn hồi và mở rộng. Tuy nhiên, bạn phải xem xét tất cả các khía cạnh của nhu cầu hiệu suất của các ứng dụng khác nhau: khả năng mở rộng dữ liệu, người sử dụng khả năng mở rộng, truy cập và tốc độ tải, nhu cầu khối lượng công việc cách ly, sự phụ thuộc vào song song và tối ưu hóa, độ tin cậy trong sự hiện diện của những thất bại, sự phụ thuộc vào sự trùng lặp lưu trữ hoặc phân phối dữ liệu và nhân rộng, trong sự kỳ vọng khác. Sau đó kiểm tra xem các nhu cầu hoạt động của các loại khác nhau của các ứng dụng được đề cập bởi mỗi kiến trúc. . Điều này sẽ cung cấp một phương pháp đo lường để đánh giá công nghệ phù hợp các bài tập 6,8 TƯỞNG Với tiền đề của phương pháp tiếp cận để thiết bị kiến trúc, đây là một số câu hỏi và bài ​​tập để suy nghĩ: • Đối với ba loại dữ liệu ứng dụng điển hình nhất lớn, mô tả sự mong đợi của bạn cho nhu cầu lưu trữ dữ liệu , loại thiết bị là tốt nhất, và các nhu cầu quản lý dữ liệu là gì? • Xây dựng một quy mô chấm điểm từ 1 đến 5 (trong đó 1 đại diện cho một nhu cầu thấp và 5 đại diện cho một nhu cầu rất lớn) cho mỗi biến được coi cho các yêu cầu lưu trữ (mở rộng khả năng tiếp cận, khả năng chịu lỗi, I / O tốc độ, integratability). Xếp hạng ba ứng dụng của bạn bằng cách sử dụng quy mô xác định của bạn. • Những biến bạn sẽ xem xét để đánh giá chi phí so sánh và lợi ích của một thiết bị phần mềm so với một thiết bị phần cứng là gì?