Các lựa chọn và kết hợp chúng tôi có sẵn trong quá trình lựa chọn kho dữ liệu cho thấy chúng tôi không còn ở trong thế giới kho dữ liệu một kích thước phù hợp với tất cả.
Ngày nay, có những lý do thuyết phục để trộn và kết hợp các kho dữ liệu SQL của bạn (chẳng hạn như MySQL, PostgreSQL, Oracle hoặc SQLServer) với các kho dữ liệu NoSQL của bạn (MongoDB, CouchDB và Neo4J trong số những người khác). doanh nghiệp, đây không còn là trò chơi duy nhất trong thị trấn.
Các nhà phát triển đang bắt đầu sử dụng kết hợp SQL và NoSQL để giải quyết các vấn đề của họ — đôi khi đi ngược lại mong muốn của các DBA hoặc Phòng CNTT.
Chọn công cụ phù hợp cho công việc
Có năm danh mục kho dữ liệu lớn trong thế giới ngày nay:họ cột, tài liệu, biểu đồ, khóa-giá trị và quan hệ. Tính liên tục đa ngôn ngữ theo nghĩa đen có nghĩa là sử dụng nhiều ngôn ngữ để lưu trữ hoặc duy trì dữ liệu của bạn. Nói một cách thực tế hơn, điều này có nghĩa là chúng tôi có thể sử dụng Cypher, JSON, SQL hoặc một số ngôn ngữ truy vấn khác để truy cập dữ liệu của chúng tôi từ trong cùng một ứng dụng. Sử dụng các kho dữ liệu khác nhau này và các ngôn ngữ khác nhau của họ đang trở nên nổi bật hơn khi các nhà phát triển tìm kiếm các công cụ tốt hơn để đưa ra các giải pháp cho nhu cầu bền bỉ của họ.
Sadalage và Fowler lưu ý sự cần thiết của tính bền bỉ đa ngôn ngữ trong NoSQL Distilled bằng cách nói:
Các cơ sở dữ liệu khác nhau được thiết kế để giải quyết các vấn đề khác nhau. Việc sử dụng một công cụ cơ sở dữ liệu duy nhất cho tất cả các yêu cầu thường dẫn đến các giải pháp không hiệu quả; lưu trữ dữ liệu giao dịch, lưu trữ thông tin phiên vào bộ nhớ đệm, biểu đồ chuyển qua [sic] của khách hàng và sản phẩm mà bạn bè của họ đã mua về cơ bản là những vấn đề khác nhau.
Hãy nghĩ đến các mối quan hệ dữ liệu. Các giải pháp RDBMS rất tốt trong việc thực thi các mối quan hệ đó tồn tại.>
Lựa chọn kho dữ liệu phụ thuộc vào hai tiêu chí:
- Cấu trúc của dữ liệu đang được lưu trữ
- Các truy vấn đang được sử dụng để tương tác với dữ liệu
Cách chúng ta truy vấn dữ liệu thay đổi cách chúng ta cấu trúc nó. Như Sadalage và Fowler đã nêu ở trên, kho dữ liệu quan hệ vượt trội trong việc thực thi các thực thể liên quan; tuy nhiên, chúng cản đường ngay khi chúng ta cần khám phá các mối quan hệ khác giữa các thực thể đó.
Dưới đây, tôi thảo luận về một trường hợp sử dụng, lưu trữ dữ liệu CraigsList với MongoDB và suy đoán về cách họ có thể đã thực hiện điều này.
Các trình phát:MongoDB, MySQL và CraigsList
MongoDB
MongoDB đã trở thành một lựa chọn thay thế NoSQL được ưa chuộng cho MySQL. Nhiều lợi ích của nó bao gồm khả năng mở rộng, tự động phân mảnh và có sẵn các ràng buộc gốc cho các ngôn ngữ lập trình phổ biến hiện nay. sử dụng tập hợp các bảng có ràng buộc khóa ngoại để thực thi các mối quan hệ, dữ liệu trong MongoDB được biểu diễn dưới dạng một tập hợp các tài liệu.
Các tài liệu tương tự (không giống nhau) với các hàng hoặc bộ dữ liệu trong cấu trúc dữ liệu quan hệ. Các truy vấn hoặc chỉ mục Thông thường có thể đạt được một bản trình bày dữ liệu tốt cho MongoDB bằng cách bất chuẩn hóa dữ liệu phù hợp với cơ sở dữ liệu quan hệ. Tất nhiên, các truy vấn cụ thể mà bạn muốn thực hiện sẽ hướng dẫn quá trình này.
Bạn có thể tìm thêm thông tin về các sắc thái của MongoDB trên trang web của MongoDB.
MySQL
MySQL cổ điển mà mọi người đều biết và yêu thích, đã xuất hiện từ buổi bình minh (trong các thang đo thời gian tính toán) và dễ dàng là DBMS được sử dụng rộng rãi nhất. Những ngày này khi mọi người nghĩ về một cơ sở dữ liệu quan hệ, họ có thể nghĩ đến MySQL.
MySQL cung cấp cho chúng ta việc triển khai mô hình dữ liệu quan hệ cổ điển. Sử dụng lý thuyết kiểu và lý thuyết tập hợp, nó được phát triển vào những năm 1970 bởi E.F. Codd. , các kho dữ liệu này tiếp tục được ưa chuộng vì chúng giải quyết vấn đề lập mô hình dữ liệu theo cách chung.
CraigsList
Một doanh nghiệp trực tuyến nổi tiếng sử dụng cả kho dữ liệu MongoDB và MySQL là CraigsList.
Do các yêu cầu quy định, Craigslist phải lưu giữ hồ sơ kỹ thuật số về các tin rao vặt của mình. Với hơn một triệu tin rao vặt mới mỗi ngày, đó là một lượng dữ liệu đáng kể để CraigsList lưu giữ. MongoDB được sử dụng để lưu trữ dữ liệu đã lưu trữ — có thể là bất cứ thứ gì trong vòng 30 ngày. di chuyển giản đồ.
Như một thử nghiệm suy nghĩ, tôi muốn suy đoán về một cách triển khai khả thi để sử dụng MongoDB và MySQL song song trong một ứng dụng CraigsList-esque. cách xem nhiều kho dữ liệu có thể hoạt động cùng nhau như thế nào cho một trang web quen thuộc, có tính giao dịch cao.
Nó được thực hiện như thế nào?
Các nhà phát triển và kỹ sư chắc chắn gặp phải sự cố khi họ thực hiện cập nhật lược đồ trên một cơ sở dữ liệu SQL cồng kềnh. tỷ lệ với lượng dữ liệu.
Trong ví dụ của chúng ta, hãy tưởng tượng CraigsList yêu cầu một phần thông tin mới từ người dùng bán một mặt hàng. Bởi vì lược đồ phải được cập nhật, CraigsList muốn giảm kích thước của dữ liệu bị ảnh hưởng để giảm thiểu sự cố cập nhật.
Sau một vài chu kỳ lưu trữ và di chuyển này, CraigsList sẽ xây dựng một bộ sưu tập dữ liệu không đồng nhất khổng lồ yêu cầu một kho dữ liệu không có schemaless nếu nó nằm ở một vị trí duy nhất.
Một lược đồ ví dụ cho phân loại sẽ trông giống như sau (được triển khai lại một cách đáng xấu hổ từ craigslist-clone):
CREATE TABLE `classifieds` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`title` varchar(75) COLLATE utf8_unicode_ci DEFAULT NULL,
`description` text COLLATE utf8_unicode_ci,
`location` varchar(75) COLLATE utf8_unicode_ci DEFAULT NULL,
`adtype` varchar(1) COLLATE utf8_unicode_ci DEFAULT 'O',
`email` varchar(75) COLLATE utf8_unicode_ci DEFAULT NULL,
`phone` varchar(75) COLLATE utf8_unicode_ci DEFAULT NULL,
`activation_code` varchar(40) COLLATE utf8_unicode_ci DEFAULT NULL,
`status` tinyint(4) DEFAULT '0',
`category_id` int(11) DEFAULT NULL,
`subcategory_id` int(11) DEFAULT NULL,
`city_id` int(11) DEFAULT NULL,
`permalink` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`image_file_name` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`image_content_type` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`image_file_size` int(11) DEFAULT NULL,
`created_at` datetime DEFAULT NULL,
`updated_at` datetime DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
Tất nhiên, CraigsList rất có thể có một lược đồ khác và ít nhất đã phát hiện ra lược đồ hiện tại của họ sau một vài lần lặp lại. mã> create_at và updated_at các trường để quyết định khi nào chúng tôi sẽ lưu trữ dữ liệu có trong MySQL.
Giả sử chính sách phân loại của Craigslist tuyên bố rằng một phân loại sẽ vẫn có sẵn trên trang web trong hai tuần. Sau thời gian này, họ muốn phân loại vẫn có sẵn nhưng không nhất thiết phải hoạt động (trong MySQL). và pymongo:
Đầu tiên, chúng ta cần lấy dữ liệu ra khỏi phiên bản MySQL của mình, chúng tôi sẽ sử dụng SQLAlchemy để thực hiện điều này và yêu cầu nó giới thiệu sơ đồ của chúng tôi (làm cho mã này có thể tái sử dụng nhiều hơn cho mục đích này).
import sqlalchemy.schema
m = sqlalchemy.schema.MetaData("mysql://root:I'm required why?@192.0.2.3/craigslist")
m.reflect()
print m.tables.keys()
Nếu bạn đang kết nối thành công với cơ sở dữ liệu của mình, bạn sẽ thấy các khóa (tên cột) của mình được in ra theo kiểu python tiêu chuẩn: [u'classifieds ', u'cities', u'subcategories ', u'categories' ] Chúng ta vẫn cần lấy từng mục dữ liệu riêng lẻ ra khỏi các bảng này.
Bây giờ chúng ta đã có các định nghĩa bảng từ phần nội quan. Đã đến lúc tạo bản đồ đối tượng hoặc truy vấn các bảng đó để lấy các mục dữ liệu mà chúng chứa. người đọc).
import sqlalchemy.sql
connection = m.bind.connect()
classifieds = m.tables['classifieds']
query = classifieds.select()
result = connection.execute(query)
for row in result:
print dict(row.items())Đoạn mã này sử dụng kết nối MySQL của chúng tôi để truy vấn tất cả các tin rao vặt. Nó có thể dễ dàng được mở rộng để xử lý tất cả các bảng, chuẩn hóa dữ liệu để phù hợp hơn với kiểu tài liệu của MongoDB. trên bảng rao vặt. Tại thời điểm này, chúng tôi đã chuyển đổi từng mục riêng lẻ trong bảng phân loại thành một từ điển, đó chính là thứ chúng tôi cần để chèn nó vào MongoDB thông qua pymongo.
Mẫu tiếp theo cho thấy cách kết nối và chèn từ điển vào pymongo:
import pymongo
client = pymongo.MongoClient('mongodb://192.0.2.2')
db = client['craigslist']
collection = db['classifieds']
collection.insert({'_id': 1})
Vấn đề duy nhất bây giờ là cách SQLAlchemy và MongoDB chỉ định ID của họ. QLAlchemy sử dụng khóa id trong khi MongoDB sử dụng khóa _id Do đó, chúng ta cần dịch khóa đó (một quá trình khá đơn giản): crypt ['_ id'] =ified.pop ('id') .
Kết luận
Mặc dù kho dữ liệu SQL và NoSQL thường được mô tả như một mệnh đề tất cả hoặc không có gì, nhưng hóa ra chúng có thể được sử dụng cùng nhau để giải quyết các vấn đề phức tạp. Kho dữ liệu MySQL. Trên thực tế, điều này có thể được thúc đẩy bởi cron chứ không phải là daemonized.
Khó khăn trong việc sử dụng nhiều kho dữ liệu không nhất thiết nằm ở việc phát triển mã dịch hoặc mã di chuyển, nhưng việc quản lý các hệ thống bổ sung sẽ làm tăng khó khăn. nhu cầu về kiến thức chuyên môn tăng lên khi bạn giới thiệu nhiều kho dữ liệu hơn.
Doanh nghiệp phải quyết định xem việc chạy nhiều kho dữ liệu có giá trị hay không. Có những công nghệ sẽ giúp giảm thiểu những thách thức này.
Ngoài các kỹ thuật tự động hóa như Chef và Salt, thách thức này có thể được giảm thiểu bằng cách tận dụng lợi thế của các nhà cung cấp dịch vụ như ObjectRocket, dịch vụ MongoDB được quản lý bởi Rackspace. , đừng để những giả định ngăn bạn khám phá những giải pháp đó.