2009-04-16 25 views
6

1) Đối với mục đích thực sự va chạm băm thấp, tôi có thể lấy đi chỉ bằng cách sử dụng một nửa trong số 128 bit của một sha1 chứ không phải là đối phó với sha1 chính nó? Tôi hiểu điều này là không thích hợp cho băm mật mã, nhưng tôi chỉ cần băm cho các khóa bảng băm.OK để chỉ sử dụng 64 bit bit băm sha1 làm id?

2) Thời gian tính toán không phải là ưu tiên và bên cạnh đó tôi đang băm nhỏ các mẩu dữ liệu rất nhỏ. Đặc biệt, tôi chủ yếu sẽ lấy 2 hoặc 3 băm 64 bit và băm chúng để có được một băm 64 bit khác. Có một lựa chọn tốt hơn so với sha1 cho mục đích này? Một lần nữa, va chạm sẽ rất khó xảy ra.

3) Tôi là một newb sql. Nó là một ý tưởng tốt để sử dụng băm 64-bit như id trong sql? Liệu các lỗi 64-bit có gây ra các vấn đề về hiệu suất trong sqlite hoặc postgres không? Tôi sẽ cần phối hợp dữ liệu trên nhiều cơ sở dữ liệu (bao gồm cả chỉ mục Lucene), vì vậy tôi thấy rằng tôi nên xử lý trực tiếp các hash trong bảng chứ không phải làm việc với các id tự động tăng (chỉ có ý nghĩa trong một db chứ không phải trên tất cả các cửa hàng dữ liệu). Tôi hình 64-bit là một thỏa hiệp tốt: đủ lớn để không va chạm nhưng tiết kiệm không gian (và thời gian tra cứu?).

4) Còn CRC-64 thì sao? Điều đó có tạo ra phân phối đủ ngẫu nhiên không?

Trả lời

6

Nếu bạn có ít hồ sơ đủ, gần như chắc chắn rằng bạn sẽ không bao giờ có xung đột băm trong 64 bit. Có khả năng bạn sẽ rơi vào thể loại này.

nên không có vấn đề với việc cắt bớt mã băm mật mã như sha1, vì nếu có cấu trúc bên trong trong băm thì sẽ không đủ tốt để trở thành băm mật mã, và nếu không có cấu trúc thì tập con của các bit nên khá ngẫu nhiên. Lưu ý rằng tôi chỉ nói về việc sử dụng ID đó cho các ID, không phải cho bất kỳ mục đích mã hóa nào!

Nhưng thực sự, SQL của bạn có một số loại GUID không? Và nếu có, tại sao không sử dụng nó?

+0

Tôi đoán GUID/UUID là khá nhiều những gì tôi muốn. Không chắc chắn nếu hỗ trợ sqlite là đủ mặc dù, vì vậy tôi sẽ điều tra điều đó. Như tôi đã nói, tôi là một newb sql. – Jegschemesch

+0

Sqlite3 có thể dễ dàng mở rộng để hỗ trợ UUID, và tôi đã thực hiện thành công như vậy trong một ứng dụng iPhone trước đây. –

+0

tôi đồng ý với câu trả lời này. tôi có một bảng đầy hundrets của hàng triệu hàng và sử dụng 64 bit đầu tiên như là phím số nguyên unsgined thay vì một băm sha1 như chuỗi vì lý do hiệu suất. với 350 triệu hàng tôi đã có một số va chạm với 56 bit. tôi luôn kết hợp khóa băm 64 bit với ngày tháng của nó sao cho cả băm và ngày cần phải khớp. Sử dụng phương pháp đó tôi chỉ có 30 triệu hàng mỗi ngày có thể gây ra va chạm, làm giảm đáng kể cơ hội xảy ra trong thời gian dài. một vụ va chạm sẽ dẫn đến một sự bình an duy nhất của thông tin được đặt sai - trong trường hợp của tôi có giá trị tiết kiệm. – bhelm

0

Nếu thời gian tính toán không quan trọng tại sao không đi toàn bộ 128 bit? Có lý do thực sự nào để chọn 64 bit bên cạnh các vấn đề lưu trữ có thể xảy ra không? (và sau đó thêm 8 byte sẽ không giết bạn với dung lượng quá rẻ)

64 bit và 128 bit sẽ không gây ra vấn đề về tốc độ trong SQLite, tôi không chắc chắn về mySQL.

+0

tôi nghĩ khi sử dụng dữ liệu băm ngẫu nhiên làm khóa, hầu hết các hệ thống cơ sở dữ liệu hiệu quả hơn với các hoạt động tìm kiếm và tham gia nếu khóa khớp với số nguyên gốc của máy thay vì chuỗi. – bhelm

3

phím của bạn sẽ cần tuyệt đối tính độc đáo không xác suất cao về tính duy nhất. Tôi sẽ đề nghị sử dụng GUIDs thay vì băm cho các phím của bạn cho khả năng tương thích chéo cơ sở dữ liệu. Tạo hàm băm như một cơ chế tra cứu nhanh - bạn có thể có một chỉ mục không duy nhất về điều này - nhưng trong trường hợp va chạm, bạn sẽ phải so sánh dữ liệu thực tế để đảm bảo chúng giống nhau. Trong đồng bộ hóa cơ sở dữ liệu của bạn, bạn có thể kiểm tra băm (nhanh chóng sử dụng chỉ mục) và nếu bạn tìm thấy một va chạm, sau đó giải quyết cho dù dữ liệu là như nhau và, do đó GUIDs cần phải được giải quyết. Nếu không có va chạm, sau đó chỉ cần cập nhật cơ sở dữ liệu nào cần mục nhập bị thiếu và chèn bằng GUID từ cơ sở dữ liệu khác.

Tôi cũng thấy ít điểm trong việc tạo băm băm của riêng bạn để tiết kiệm dung lượng. Nếu bạn đã có các băm khác, chỉ cần sử dụng chúng (nối thêm, không rehash). Nếu không, chỉ cần sử dụng hàm băm tiêu chuẩn như MD5 hoặc SHA1 và lưu trữ dữ liệu kết quả.

+1

Nhưng tại sao tôi cần tính duy nhất tuyệt đối? Chúng ta không nói về xác suất RẤT cao sao? 1 trong 2^128 cơ hội mà bất kỳ hai mục có cùng một băm, phải không? Có lẽ chúng ta cũng không lo lắng về việc bị tấn công bởi một thiên thạch? Hoặc làm MD5 và sha1 không phân phối đủ ngẫu nhiên? – Jegschemesch

+0

Ah, tôi nghĩ rằng chúng ta đang nói chuyện với nhau bởi vì tôi đã không biết gì về GUID/UUID trong khi bạn dường như cho rằng tôi đã không. Nhưng GUID cũng không phải là độc đáo, đúng không? – Jegschemesch

+0

Có. Các id duy nhất trên toàn cầu (hoặc phổ biến) là hoàn toàn độc đáo. Thuật toán tạo ra đảm bảo rằng không có hai máy nào tạo ra cùng một id. Quan điểm của tôi là nếu bạn đang sử dụng nó như là một khóa chính, bạn không thể chịu đựng được ngay cả một va chạm, dù có hiếm đến mức nào. – tvanfosson

2

Với băm 64 bit, bạn có 1% cơ hội va chạm với 6.1 × 10 bản ghi. (Đối với các kết hợp khác, xem page on the Birthday problem của Wikipedia.) Bạn có thể vứt bỏ 64 bit đầu tiên hoặc cuối cùng của mỗi bit thứ hai, nó không tạo ra bất kỳ sự khác biệt nào với các thuộc tính của băm.

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