2009-07-28 23 views
5

Tôi hiện đang sử dụng JSON (nén qua gzip) trong dự án Java của mình, trong đó tôi cần lưu trữ một số lượng lớn đối tượng (hàng trăm hàng triệu) trên đĩa. Tôi có một đối tượng JSON trên mỗi dòng và không cho phép các dấu ngắt dòng trong đối tượng JSON. Bằng cách này, tôi có thể truyền dữ liệu ra khỏi đĩa theo từng dòng mà không phải đọc toàn bộ tệp cùng một lúc.Tìm kiếm định dạng tuần tự nhanh, gọn, dễ đọc, đa ngôn ngữ, được nhập mạnh

Nó chỉ ra rằng phân tích cú pháp mã JSON (sử dụng http://www.json.org/java/) là một chi phí lớn hơn là kéo dữ liệu thô ra khỏi đĩa, hoặc giải nén nó (mà tôi làm trên bay). Lý tưởng nhất mà tôi muốn là định dạng tuần tự được đánh máy mạnh, nơi tôi có thể chỉ định "trường đối tượng này là danh sách chuỗi" (ví dụ) và vì hệ thống biết điều gì sẽ xảy ra, nó có thể deserialize nó Mau. Tôi cũng có thể chỉ định định dạng chỉ bằng cách cho người khác "loại" của nó.

Nó cũng cần phải là nền tảng chéo. Tôi sử dụng Java, nhưng làm việc với những người sử dụng PHP, Python và các ngôn ngữ khác.

Vì vậy, để tóm tắt, nó phải là:

  • mạnh gõ
  • streamable (tức là đọc một chút tập tin bằng chút mà không cần phải tải tất cả vào RAM cùng một lúc.)
  • Cheo nền (bao gồm cả Java và PHP)
  • nhanh
  • miễn phí (như trong bài phát biểu)

Bất kỳ con trỏ nào?

+0

Nếu kéo dữ liệu thô ra khỏi đĩa nhanh hơn, tại sao không làm điều đó? Tại sao lộn xộn với JSON nếu nó chậm hơn? –

+0

Được rồi, vì vậy việc phân tích cú pháp json chậm hơn việc giải nén hoặc đọc dữ liệu khỏi đĩa. Vậy cái gì? Có quá chậm cho những gì bạn cần làm không? Hay bạn đang tối ưu hóa chỉ vì lợi ích của nó? – Breton

+0

Breton: nó quá chậm so với những gì tôi cần làm, nó không phải là một tối ưu hóa sớm. – sanity

Trả lời

8

Bạn đã nhìn buffers Google Nghị định thư ?:

http://code.google.com/apis/protocolbuffers/

Họ nền tảng chéo (C++, Java, Python) với các ràng buộc của bên thứ ba cho PHP cũng có. Đó là nhanh chóng, khá nhỏ gọn và mạnh mẽ đánh máy.

Ngoài ra còn có một so sánh hữu ích giữa các định dạng khác nhau ở đây:

http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

Bạn có thể muốn xem xét việc tiết kiệm hoặc một trong những người khác đề cập ở đây là tốt.

+0

... và, có Google ủng hộ nó. –

2

Bạn có thể có một cái nhìn tại YAML- http://www.yaml.org/

Đó là một superset của JSON vì thế cấu trúc tập tin dữ liệu sẽ được làm quen với bạn. Nó hỗ trợ một số loại dữ liệu bổ sung cũng như khả năng sử dụng tài liệu tham khảo bao gồm một phần của một cấu trúc dữ liệu vào cấu trúc dữ liệu khác.

Tôi không có ý tưởng nào nếu nó sẽ "đủ nhanh" - nhưng trình phân tích cú pháp libyaml (viết bằng C) có vẻ khá linh hoạt.

+0

Trong khi Yaml là không có cách nào một superset của JSON, tôi đồng ý rằng nó là một trong những định dạng dễ đọc/nhỏ nhất/gõ tôi biết. – gizmo

+0

yaml là cách phức tạp hơn so với json. Tôi nghĩ rằng hầu hết các triển khai đều chậm hơn. – troelskn

+0

AFAIK, vâng, việc triển khai không thực sự hiệu quả. YAML được hướng tới một số mục tiêu khác nhau, khả năng diễn đạt tối đa và vân vân, chứ không phải tốc độ hay sự đơn giản. – StaxMan

3

Tôi đã có kết quả rất tốt phân tích cú pháp JSON với Jackson

Jackson là một:

  • streaming (đọc, viết)
  • FAST (đo được nhanh hơn bất kỳ json phân tích cú pháp Java khác và dữ liệu liên kết)
  • Mạnh mẽ (ràng buộc đầy đủ dữ liệu cho các lớp JDK thông thường cũng như bất kỳ lớp Java nào, Bộ sưu tập, Bản đồ hoặc Enum)
  • Không phụ thuộc cy (không dựa vào các gói khác ngoài JDK)
  • mã nguồn mở (LGPL hoặc AL)
  • Hoàn toàn tuân thủ QTI

xử JSON (JSON phân tích cú pháp + phát JSON) viết bằng Java. Ngoài đọc/ghi JSON cơ bản (phân tích cú pháp, tạo), nó cũng cung cấp đầy đủ mô hình cây dựa trên nút, cũng như đầy đủ chức năng ràng buộc dữ liệu OJM (Object/Json Mapper).

performance của nó là rất tốt khi so sánh với nhiều tùy chọn tuần tự hóa khác.

+0

Sử dụng Jackson trước khi thử bất cứ điều gì khác. Mã trên json.org không phù hợp để sử dụng sản xuất. –

Các vấn đề liên quan