Sử dụng cơ sở dữ liệu quan hệ so với các đối tượng JSON cho dữ liệu sự kiện / hoạt động


28

Tôi đang làm việc trên một dự án nơi tôi đang cố gắng quyết định giữa việc sử dụng cơ sở dữ liệu quan hệ SQL hoặc các đối tượng JSON tiêu chuẩn để lưu trữ dữ liệu về một sự kiện hoặc hoạt động.

Dự án sẽ lưu trữ dữ liệu về nhiều loại sự kiện vì vậy tôi đã quyết định chỉ mô tả một loại sự kiện cho câu hỏi này.

Sự kiện âm nhạc trực tiếp (được mô tả đầy đủ bằng lược đồ JSON ở cuối câu hỏi này) là một đối tượng lưu trữ dữ liệu như nơi sự kiện sẽ diễn ra, thời gian / ngày của sự kiện và chi phí của sự kiện. Đối tượng sự kiện âm nhạc trực tiếp có cả một đối một (sự kiện -> tên, sự kiện -> mô tả) và một-nhiều (sự kiện -> địa điểm, sự kiện -> ngày, sự kiện -> loại vé ) các mối quan hệ. Hơn nữa, đối tượng sự kiện có thể chứa một hoặc nhiều ID người thực hiện, liên kết đến đối tượng người thực hiện. Đối tượng biểu diễn lưu trữ dữ liệu về các nhạc sĩ đang biểu diễn tại sự kiện âm nhạc trực tiếp.

Dữ liệu sẽ được người dùng truy vấn bằng cả hai cách đơn giản ("Tìm tôi sự kiện với 'x' tên") và phức tạp ("Tìm tôi sự kiện với thể loại nhạc 'x' và chi phí 'y' trong bán kính 'z' từ hiện tại của tôi vị trí ") truy vấn. Dữ liệu sẽ được gửi bởi người dùng bằng mẫu web.

Như bạn có thể biết từ lược đồ JSON đã xác định, ban đầu tôi sẽ sử dụng các đối tượng JSON để lưu trữ dữ liệu này nhưng tôi đã nghe một số người nói rằng vì dữ liệu của tôi hoàn toàn là quan hệ, tôi nên tuân theo các phương thức cũ hơn.

Tôi sẽ đánh giá cao bất kỳ suy nghĩ về ưu và nhược điểm của từng phương pháp cho nhu cầu của tôi. Nếu bạn cần bất cứ điều gì làm rõ, xin vui lòng hỏi.

{
    "event": {
        "eventID":{
            "type":"string"
        },  
        "eventType":{
            "type":"array",
            "eventTypeItem":{
                "type":"string"
            }
        },
        "eventName":{
            "type":"string"
        },      
        "eventDescription":{
            "type":"string"
        },
        "eventVenueList":{
            "type":"array",
            "eventVenueListID":{
                "type":"integer"
            }
        },
        "eventURL":{
            "type":"string"
        },
        "eventTwitter":{
            "type":"string"
        },
        "eventFB":{
            "type":"string"
        },
        "eventInstagram":{
            "type":"string"
        },
        "eventEmail":{
            "type":"string",
            "format":"email"
        },
        "eventContactPerson":{
            "type":"string"
        },
        "eventDoorTime": {
            "type":"string",
            "format":"date-time"
        },  
        "eventPerformerIDList":{
            "type":"array",
            "liveMusicPerformerID":{
                "type":"integer"
            }
        },  
        "eventSetList":{
            "type":"array",
            "eventPerformerID":{
                "type":"integer"
            },
            "eventPerformerStartTime":{
                "type":"string",
                "format":"date-time"
            },
            "eventPerformerEndTime":{
                "type":"string",
                "format":"date-time"
            }                                   
        },
        "eventDateList": {
            "type":"array",
            "eventDateItem": {
                "type":"string",
                "format":"date-time"
            }   
        },
        "eventDateStartTime": {
            "type":"string",
            "format":"date-time"
        },
        "eventDateEndTime": {
            "type":"string",
            "format":"date-time"
        },
        "eventTicket":{ 
            "type":"array",
            "eventTicketType":{
                "type":"string" 
            },
            "eventTicketLowPrice":{
                "type":"number"
            },
            "eventTicketHighPrice":{
                "type":"number" 
            },
            "eventDatesAdvancePrice": {
                "type":"number"
            }   
        }
    },  
    "performer": {
        "performerID": {
            "type":"integer"
        },
        "performerType": {
            "type":"string"
        },
        "performerName": {
            "type":"string"
        },
        "performerAlternateName": {
            "type":"array",
            "performerAlterateNameItem":{
                "type":"string"
            }
        },
        "performerGenreList": {
            "type":"array",
            "performerGenreItem":{
                "type":"string"
            }
        },
        "performerURL": {
            "type":"string"
        }                                       
    }
}   

Tôi không biết các yêu cầu của trang web, nhưng tôi muốn tìm kiếm theo: người biểu diễn, địa điểm và có thể là ngày. Đây sẽ là một vấn đề vì chúng được tổ chức trong các loại mảng?
JeffO

Bạn có thể không lập trình truy vấn của bạn để tìm kiếm các giá trị trong mảng có liên quan?
zgall1

13
JSON không phải là một định dạng lưu trữ. Đúng, bạn có thể lưu trữ dữ liệu bằng các tệp văn bản của nội dung, nhưng chỉ trong các tình huống đơn giản nhất. JSON "mới hơn" so với cơ sở dữ liệu quan hệ không liên quan đến quyết định của bạn.
Robert Harvey

1
Tôi nhận ra nó không phải là một định dạng lưu trữ. Tôi có nghĩa là tôi có thể sử dụng đối tượng JSON của MongoDB hoặc Postgre để lưu trữ dữ liệu với định dạng JSON.
zgall1

2
@RobertHarvey và cử tri, ngày nay (2017) JSON một định dạng cửa hàng : xem PostgreQuery 9.6+ ... Cơ bản kể từ ~ 2012, chuyên nghiệp và trưởng thành kể từ cuối năm 2015 (kiểu dữ liệu JSONb).
Peter Krauss

Câu trả lời:


45

Tôi nghĩ rằng câu hỏi của bạn thực sự sôi nổi: Khi nào tôi nên sử dụng cách tiếp cận NoQuery so với RDBMS? Bạn đã giải quyết JSON sớm (một quyết định của NoQuery-ish), có lẽ vì bạn đã có người tiêu dùng Ajax.

Tất nhiên, câu trả lời là khi nào nên sử dụng các cách tiếp cận của NoQuery so với RDBMS về cơ bản là về loại dữ liệu bạn đang làm việc và những gì người tiêu dùng bạn dự đoán có. Nếu dữ liệu của bạn về cơ bản là quan hệ (phân cấp khá phẳng, không có loại dữ liệu lạ như hình ảnh hoặc âm thanh, mối quan hệ có thể dự đoán giữa các lược đồ có thể dễ dàng mô tả trong các khóa) và người tiêu dùng của bạn dự kiến ​​sẽ bao gồm những người muốn thực hiện truy vấn Business Intelligence (truy vấn ad hoc), sau đó RDBMS là cách để đi. Thật dễ dàng để biến một truy vấn thành một đại diện JSON, vì vậy nó không gây gánh nặng đáng kể cho người tiêu dùng Ajax của bạn - nó chỉ thêm một chút chuyển đổi mã hóa vào các điểm cuối của bạn (REST / SOAP / bất cứ điều gì). Ngược lại, nếu dữ liệu của bạn rất phân cấp (lược đồ sâu), chứa các loại dữ liệu kỳ lạ như hình ảnh, âm thanh, video, v.v., có một vài mối quan hệ giữa các thực thể và bạn biết rằng người dùng cuối của bạn sẽ không thực hiện BI, sau đó NoQuery / lưu trữ JSON có thể phù hợp.

Tất nhiên, ngay cả những hướng dẫn chung này cũng không vững chắc. Lý do Google phát triển Hệ thống tệp của Google, MapReduce (công việc được Doug Cutting sử dụng để xây dựng Hadoop tại Yahoo) và sau đó là BigQuery (một cách quản lý dữ liệu quy mô lớn theo định hướng NoQuery) chính xác là họ có rất nhiều quảng cáo Yêu cầu BI, và họ không thể có được các cách tiếp cận quan hệ để mở rộng quy mô tera / peta / exa / zetta / yotta mà họ đang cố gắng quản lý. Cách tiếp cận thực tế duy nhất là mở rộng quy mô, hy sinh một số tính thân thiện với người dùng truy vấn đặc biệt mà RDBMS cung cấp và thay thế một thuật toán đơn giản (MapReduce) có thể được mã hóa khá dễ dàng cho bất kỳ truy vấn nào.

Với lược đồ của bạn ở trên, câu hỏi của tôi về cơ bản sẽ là: Tại sao bạn không sử dụng RDBMS? Tôi không thấy nhiều lý do để không. Nghề nghiệp của chúng tôi được cho là định hướng kỹ thuật, không định hướng thời trang, vì vậy bản năng của chúng tôi là chọn giải pháp đơn giản nhất có hiệu quả, phải không? Ý tôi là, các điểm cuối của bạn có thể phải thực hiện một chút dịch nếu người tiêu dùng của bạn là Aj Wax, nhưng dữ liệu của bạn trông rất phẳng và có vẻ như người dùng doanh nghiệp sẽ muốn thực hiện tất cả các loại truy vấn ad hoc trên các sự kiện như sự kiện âm nhạc (Mà sự kiện này được tham dự nhất trong vòng 50 dặm của thành phố thủ đô của chúng tôi năm ngoái?)

'Đừng đến yêu tinh để được tư vấn, vì họ sẽ nói cả không và có.' - Frodo


"Nghề nghiệp của chúng tôi được cho là định hướng kỹ thuật, không định hướng thời trang, vì vậy bản năng của chúng tôi nên chọn ..." Giải pháp TỐT NHẤT nào hiệu quả? ;)
Bink

5

Tôi tin rằng có nhiều cân nhắc ở đây mà bạn có thể không tìm kiếm. Có hai mối quan tâm rộng lớn ở đây:

  • Lưu trữ
  • Tìm kiếm và truy xuất

Lưu trữ

Có rất nhiều ý kiến ​​về lý do tại sao nên sử dụng cửa hàng không có sql hoặc RDBMS cho dữ liệu của bạn. Một trong những mục quan trọng nhất mà chúng tôi nghĩ là hữu ích là chúng tôi có thể dễ dàng xác định và lưu trữ các đối tượng json trong kho mà không phải lo lắng về việc xác định cấu trúc đầy đủ hoặc mối quan hệ giữa các loại đối tượng khác nhau. Một số lý do khác để sử dụng db NoSql là khả năng tự động phân đoạn dữ liệu, tìm kiếm dựa trên vị trí và bảo trì dễ dàng. Có rất nhiều cơ sở dữ liệu NoSql tốt, sở thích cá nhân của tôi là MongoDB. Tuy nhiên, nếu bạn chưa sử dụng cơ sở dữ liệu NoSql trước đây, có một đường cong học tập xác định khi bạn học cách nối lại tâm trí của bạn. Hầu hết chúng ta đã sử dụng RDBMS được một thời gian và phải nỗ lực có ý thức để thoát khỏi thói quen đó. Thêm vào đó, bạn sẽ thấy mình muốn làm lại mô hình dữ liệu của mình khi bạn tiến hành cùng với những nỗ lực của mình và hiểu rõ hơn về các khái niệm. Nếu khả năng tái cấu trúc hoặc sửa sang lại không phải là một lựa chọn cho dự án của bạn, tôi sẽ đề nghị gắn bó với những gì bạn đã biết rõ nhất.

Tìm kiếm

Nếu bạn có ý định cung cấp bất kỳ loại tìm kiếm nào có thể sử dụng được, tôi thực sự khuyên bạn nên sử dụng một công cụ tìm kiếm văn bản chuyên dụng như SOLR để thực hiện các tìm kiếm của mình. Tìm kiếm văn bản chậm và nếu bạn có nhiều phân đoạn thì thậm chí còn chậm hơn. SOLR hỗ trợ tìm kiếm văn bản nhanh chóng bao gồm thông số tìm kiếm có trọng số, tìm kiếm dựa trên vị trí và nhiều hơn nữa. Tuy nhiên, SOLR không phù hợp làm kho lưu trữ dữ liệu chính của bạn. Điều này không có nghĩa là bạn sẽ phải tạo các cơ chế để chèn kép và cập nhật cho cả cơ sở dữ liệu chính và lớp SOLR của bạn khi thêm hoặc cập nhật các sự kiện. Ngoài ra, bạn sẽ phải giữ cho SOLR được cập nhật sau đó bằng cách xóa mọi sự kiện đã lỗi thời / đã kết thúc.

Mặc dù điều này có vẻ như rất nhiều công việc làm thêm, bạn sẽ cảm ơn bản thân vì tầm nhìn xa của việc sử dụng một công cụ tìm kiếm toàn văn sau này. Không có cơ sở dữ liệu NoSql hoặc RDBMS nào gần với hiệu suất và sự linh hoạt của SOLR / Lucene.


3

Đầu tiên, nếu bạn đang cố lưu trữ dữ liệu JSON trong bất kỳ bộ lưu trữ nào nhưng không phải là sở dữ liệu NoQuery , tôi chắc chắn không khuyến khích bạn sử dụng JSON. Lý do là nếu bạn lưu trữ dữ liệu của mình dưới dạng tệp JSON, chẳng hạn, thì việc mở nó, phân tích dữ liệu, lặp qua nó, v.v.

Điều đó bắt đầu, tôi có thể thu hẹp câu hỏi của bạn thành: Những ưu và nhược điểm của NoQueryRDBMS là gì? Và nó đã được trả lời hàng ngàn lần trên mạng.

Theo dõi dự án của bạn, tất nhiên bạn có thể sử dụng NoQuery hoặc RDBMS ; Tuy nhiên, những gì tôi thường có thể khuyên bạn là hãy nghĩ ra và tìm kiếm các yếu tố ít nhìn thấy khác có thể giúp bạn quyết định giữa hai lựa chọn. Hãy thử xem tùy chọn nào có thể tăng tốc độ phát triển? Cái nào phù hợp hơn cho các thành viên khác trong nhóm - nếu bạn không phải là nhà phát triển duy nhất. Nếu bạn đang bán cái này, cái nào rẻ hơn, dễ dàng hơn và thường phù hợp hơn cho khách hàng không phải là nhà phát triển của bạn?

Bằng cách này, cuối cùng bạn có thể quyết định đi theo con đường nào, nếu không sẽ rất khó để quyết định dựa trên thông tin đã cho vì cả hai tùy chọn có thể phù hợp khá tốt.


2

Trong hầu hết các ứng dụng đều có yêu cầu

  1. Nhập dữ liệu, thực hiện một số xử lý, lưu dữ liệu, truy xuất dữ liệu và truy vấn dữ liệu. Cũng có thể có một yêu cầu để tạo báo cáo về dữ liệu.
  2. Trao đổi dữ liệu giữa các phần khác nhau của hệ thống hoặc với các hệ thống bên ngoài

Để đạt được các yêu cầu cho Mục 1, cần có phương pháp lưu giữ dữ liệu. Thông thường nếu khối lượng dữ liệu rất nhỏ và loại dữ liệu đơn giản và không yêu cầu khả năng tìm kiếm mở rộng thì có thể sử dụng cấu trúc tệp đơn giản. Khi dữ liệu trở nên phức tạp hơn, cấu trúc XML (hoặc thậm chí JSON) có thể được sử dụng với dữ liệu vẫn được lưu trữ trong các tệp. Tìm kiếm mặc dù trở nên có vấn đề hơn. Khi khối lượng dữ liệu tăng và độ phức tạp của tìm kiếm tăng, cơ sở dữ liệu thường được chọn, cung cấp các phương pháp tiêu chuẩn công nghiệp để duy trì dữ liệu, truy vấn, vv Các cơ sở dữ liệu có thể được thiết kế để xử lý khối lượng lớn dữ liệu và lưu trữ, truy xuất và tìm kiếm dữ liệu nhanh chóng và hiệu quả .

Để đạt được các yêu cầu cho Mục 2, có nhiều phương pháp khác nhau để cho phép trao đổi dữ liệu giữa các hệ thống bao gồm XML, JSON, v.v.

Các phương thức này cho phép cấu trúc dữ liệu được xác định bởi người dùng và độc lập với ngôn ngữ cho phép hệ thống khác nhau trao đổi dữ liệu.

Trong trường hợp cụ thể của bạn, bạn đang sử dụng JSON chính xác để mô tả một tập hợp các sự kiện âm nhạc. Mặc dù bạn có thể lưu trữ dữ liệu ở định dạng JSON tìm kiếm dữ liệu này vì số lượng sự kiện âm nhạc tăng lên sẽ chậm và không hiệu quả.

Sử dụng cách tiếp cận phân tách mối quan tâm sau đó cách tiếp cận tốt hơn là thu thập dữ liệu, lưu trữ trong cơ sở dữ liệu, thực hiện truy vấn của bạn dựa trên đầu vào của người dùng trong cơ sở dữ liệu và sau đó trả kết quả ở định dạng JSON cho phía Máy khách để hiển thị dữ liệu.

Một vấn đề khác với cách tiếp cận JSON là cấu trúc dữ liệu thay đổi. Hiện tại cấu trúc của bạn tương đối đơn giản. Bạn có thể sử dụng cấu trúc này trong vài tháng và sau đó một trường bổ sung được xác định. Sau đó, bạn sẽ làm gì với tất cả các đối tượng JSON hiện có của mình? Cập nhật những điều này sẽ có vấn đề.

Nếu bạn đã sử dụng cơ sở dữ liệu thì việc thêm một trường bổ sung tương đối đơn giản và chỉ mã của bạn để tạo JSON sẽ cần được sửa đổi ở một nơi duy nhất, do đó cung cấp cho bạn tất cả JSON mới với trường mới.

Tóm lại, sử dụng từng phần công nghệ cho những gì nó được thiết kế cho JSON để trao đổi dữ liệu và Cơ sở dữ liệu để duy trì dữ liệu.


0

Tôi nghĩ rằng bạn sẽ thành công hơn khi sử dụng NoQuery so với SQL để lưu trữ dữ liệu này, vì các truy vấn bạn cần thực hiện.

Ngoài ra, chỉ vì một số dữ liệu hoàn toàn không có ý nghĩa, nên nó phải được duy trì trong một số RDBMS (SQL). Dữ liệu quan hệ IMO sẽ dịch tốt hơn vào cơ sở dữ liệu đồ thị.

Tất nhiên bạn cũng có thể viết các truy vấn bằng SQL nhưng hiệu suất sẽ trở nên khủng khiếp vì số lượng tham gia bạn sẽ cần phải có (xem xét dữ liệu của bạn sẽ được chuẩn hóa phần nào và không phải tất cả trong một bảng Sự kiện).

Nhưng cuối cùng, bạn sẽ có nhiều tự do hơn bằng cách sử dụng NoQuery (do đó là JSON hoặc một số định dạng khác được cơ sở dữ liệu hỗ trợ) xem xét bạn có thể sửa đổi lược đồ của mình trong tương lai mà không cần tính đến dữ liệu đã tồn tại.

Xem xét NoQuery, bạn cũng có thể xem xét cơ sở dữ liệu đồ thị nếu bạn dự định sử dụng các truy vấn rất phức tạp, vì chúng sẽ mang lại cho bạn lợi thế trong việc tạo chúng dễ dàng và cũng thực hiện chúng rất nhanh.


0

Tôi nghĩ bạn nên sử dụng cả hai và tôi không xem đó là quyết định 'so với'.

Một cơ sở dữ liệu quan hệ có ý nghĩa cho việc lưu trữ và truy xuất dữ liệu nhanh chóng và hiệu quả có các thuộc tính quan hệ.

JSON là một định dạng dữ liệu tuyệt vời vì nó đơn giản, nhẹ và lý tưởng để truyền xung quanh dữ liệu thô ở định dạng rất cơ bản với cú pháp phù hợp để lưu trữ và trao đổi thông tin văn bản. Thật tuyệt vời khi truyền một lượng nhỏ dữ liệu giữa trình duyệt và máy chủ. Đây không phải là một định dạng dễ dàng để bắt đầu sử dụng cho các truy vấn dữ liệu kiểu quan hệ.

Vì vậy, tôi muốn giới thiệu SQL cho việc lưu trữ dữ liệu và JSON cho định dạng truyền dữ liệu.

Đúng là không có các tùy chọn khóa-giá trị của NoQuery như Mongo, Redis, v.v. Những điều này sẽ có lợi thế là có thể ánh xạ đơn giản hơn sang định dạng JSON nhưng thường khó sử dụng hơn cho các truy vấn. Rào cản chính với họ là sự lạ lẫm của cộng đồng CNTT nói chung, đặc biệt khi so sánh với SQL vốn rất nổi tiếng và sở hữu một lượng lớn tài nguyên và kiến ​​thức có sẵn cho hầu hết mọi tình huống có thể tưởng tượng được.


Nếu tôi tìm một lập trình viên có hiểu biết tốt về cách sử dụng phương thức lưu trữ giá trị khóa noQuery trong các truy vấn, bạn có nói rằng đó sẽ là thách thức quan trọng nhất để vượt qua khi sử dụng JSON làm định dạng lưu trữ dữ liệu?
zgall1

Tôi cá là nó sẽ đơn giản chỉ vì cấu trúc dữ liệu duy nhất nghèo / kém hơn avg. nhà phát triển biết là cơ sở dữ liệu quan hệ. Mặc dù đây là về chất lượng trung bình của các nhà phát triển và cách họ học cách tránh học, NoQuery sẽ là lựa chọn thích hợp cho dữ liệu không liên quan ... thực tế, mọi nhà thường đơn giản hơn, cho rằng dữ liệu của bạn thực sự không - quan hệ. NHƯNG bạn phải có được sự lựa chọn đúng đắn của DB, NoQuery được thực hiện hoặc phá vỡ sự lựa chọn ban đầu .. và mức độ phù hợp với dữ liệu.
JM Becker
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.