Bạn quay lại mục 3 nhé, mình có đưa ra các lí do vì sao nó lại cần thiết trong Java. Để hiểu đơn giản thì Serialization sinh ra như một cơ chế chung mà các ứng dụng Java có thể giao tiếp cũng như trao đổi dữ liệu với nhau. Cụ thể hơn bạn có thể hiểu đơn giản nó như này: Bạn tạo ra một ứng dụng Java và đặt nó trên nhiều hệ thống và mạng khác nhau. Làm sao để các hệ thống này giao tiếp và chia sẻ dữ liệu cho nhau, tất nhiên với cách truyền thống là bạn sẽ phải tự xác định một giao thức riêng, có thể là bất cứ giao thức gì bạn muốn, nhưng vấn đề đặt ra là nếu có một bên thứ 3 cũng muốn kết nối và chia sẻ dữ liệu với bạn, họ cũng sẽ phải biết được giao thức mà bạn đang sử dụng và sau này nếu có nhiều hơn các ứng dụng, hệ thống khác nhau và mỗi ứng dụng lại sử dụng một giao thức chuyển đổi khác nhau thì sao -> có phải là sẽ cực kỳ khó khăn đúng không. Chính vì thế, cần phải có một giao thức chung và hiệu quả để làm điều này -> Serialization ra đời, thay vì sử dụng các giao thức riêng lẻ, Serialization cung cấp một cơ chế chung để chuyển đối tượng giữa các thành phần Java. Từ giờ các thành phần ứng dụng Java có thể sử dụng chung cơ chế này để giao tiếp và chia sẻ dữ liệu.
@maitrungduc1410 anh ơi cả 2 lỗi này đều gây lỗi không chạy được app.
Lỗi npm ERR! missing script: serve
-Em phải thêm dòng "serve": "BROWSER=none react-scripts start" trong script
Lỗi "Browserslist: caniuse-lite is outdated. Please run next command npm update caniuse-lite browserslist"
-Em thêm " && npx browserslist@latest --update-db" để có thể chạy được
Chào bạn, cảm ơn bạn đã quan tâm đến bài viết của Viblo Engineering. Ở 2 giải pháp này, mình xin phép đưa ra ý kiến đánh giá như sau:
Tạo một index cho mỗi loại dữ liệu (theo loại dữ liệu):
Ưu điểm:
Tính cụ thể: Mỗi index sẽ chứa chỉ dữ liệu liên quan đến loại dữ liệu cụ thể, giúp tăng hiệu suất khi truy vấn dữ liệu.
Quản lý dễ dàng: Dễ dàng quản lý và duy trì các index riêng biệt cho mỗi loại dữ liệu.
Nhược điểm:
Phức tạp hóa: Có thể dẫn đến việc phải quản lý nhiều index và logic xử lý phức tạp hơn khi truy vấn dữ liệu từ nhiều index khác nhau.
Tạo một index union cho tất cả các loại dữ liệu:
Ưu điểm:
Đơn giản hóa: Giảm bớt sự phức tạp trong việc quản lý index và truy vấn dữ liệu từ một index duy nhất.
Dễ dàng mở rộng: Dễ dàng mở rộng hệ thống khi có thêm loại dữ liệu mới mà không cần thay đổi cấu trúc index.
Nhược điểm:
Hiệu suất không cao: Dữ liệu từ nhiều loại có thể không được tối ưu cho các loại truy vấn cụ thể.
Nếu yêu cầu trong dự án quan tâm đến hiệu suất và tối ưu hóa truy vấn thì tạo index cho mỗi loại dữ liệu tốt hơn. Ngược lại sẽ giúp giảm bớt sự phức tạp trong quản lý và mở rộng hệ thống.
Nếu hệ thống của bạn cho phép thì bạn cũng có thể kết hợp 2 phương pháp bằng cách:
Tạo một index union cho các loại dữ liệu chung.
Tạo index riêng biệt cho các loại dữ liệu đặc biệt hoặc có yêu cầu hiệu suất cao.
Không biết câu trả lời này đã giải đáp được thắc mắc cho bạn chưa nhỉ? Bạn cứ thoải mái đưa ý kiến và thảo luận thêm nha ^^
@Fuzzy để đọc hiểu thì hiện nay cả các phần mềm lớn của nước ngoài cũng chưa làm được cái đó, vì gồng mình xử lý đống dữ liệu đã khá là chật vật rồi, nếu áp dụng mức độ cao kiểu LLM thì tốc độ kiểm tra sẽ chậm hơn rất rất nhiều. Trước kia có 1 bên của Isarel định làm kiểu đó nhưng cũng chìm không thấy tin gì thêm, và cũng chưa bên nào làm được với kiểu dịch từ Anh sang Việt mà vẫn tìm ra. Trường hợp paraphrase thì thực tế là điểm tương đồng sẽ giảm, không phải là 100% nữa mà còn 60-70% chẳng hạn, nhưng như vậy vẫn tính là trùng (chỉ bôi vàng chứ không bôi đỏ chót). Còn nếu paraphrase mạnh quá thì sẽ coi như là câu văn mới rồi, hiện tại thì sẽ bỏ qua.
Đầu tiên thì đa phần các CSLD hiện nay đều hỗ trợ tìm kiếm unicode. Thứ 2 là bạn cần tách biệt giữa chủ đề tìm kiếm nội dung text thông thường và tìm kiếm nội dung trong một file, ví dụ bạn đưa ra vấn đề tìm kiếm 1000 chương Cẩm Y Vệ thì nó sẽ thuộc vấn đề tìm kiếm nội dung file, sẽ không ai lưu 1000 chương cẩm y vệ vào database, họ sẽ lưu nó ra file để ở 1 server, và kể cả có lưu 1000 chương vào database dạng text hoặc CLOB thì nó vẫn không thể tìm kiếm theo cách thông thương, bạn sẽ phải thực hiện nhiều bước như loại bỏ ký tự hoặc từ thừa chỉ lấy các từ khóa chính sau đó map và đánh index ..vvv. Quay lại với việc tìm kiếm nội dung của các cột thông thường, thì nếu database không hỗ trợ unicode thì bạn sẽ có 4 cách. 1 là chuyển sang không dấu, 2 là dùng fulltext search, 3 là dùng 1 search engine, 4 là bạn có thể chuẩn hóa dữ liệu unicode thành dạng phân rã (canonical decomposition - NFD) để lưu trữ và tìm kiếm
@roobinson phần check trùng thì bạn tìm từ giống nhau hay có đọc hiểu vậy nhỉ, vì có trường hợp người viết họ paraphare lại câu, nhưng bản chất vẫn là cùng một nghĩa
THẢO LUẬN
https://www.baeldung.com/java-serialization, https://www.javatpoint.com/serialization-in-java Đây là 2 bài tài liệu tiếng anh cho phần này, bạn có thể đọc thêm để hiểu hơn nhé. Nếu có vấn đề gì hay có thắc mắc gì thì comment xuống dưới, chúng mình trao đổi nhá😘
Mỗi ngôn ngữ cũng sẽ có cách khác nhau để thực hiện công việc chuyển đổi đối tượng (object serialization) này.
Bạn quay lại mục 3 nhé, mình có đưa ra các lí do vì sao nó lại cần thiết trong Java. Để hiểu đơn giản thì Serialization sinh ra như một cơ chế chung mà các ứng dụng Java có thể giao tiếp cũng như trao đổi dữ liệu với nhau. Cụ thể hơn bạn có thể hiểu đơn giản nó như này: Bạn tạo ra một ứng dụng Java và đặt nó trên nhiều hệ thống và mạng khác nhau. Làm sao để các hệ thống này giao tiếp và chia sẻ dữ liệu cho nhau, tất nhiên với cách truyền thống là bạn sẽ phải tự xác định một giao thức riêng, có thể là bất cứ giao thức gì bạn muốn, nhưng vấn đề đặt ra là nếu có một bên thứ 3 cũng muốn kết nối và chia sẻ dữ liệu với bạn, họ cũng sẽ phải biết được giao thức mà bạn đang sử dụng và sau này nếu có nhiều hơn các ứng dụng, hệ thống khác nhau và mỗi ứng dụng lại sử dụng một giao thức chuyển đổi khác nhau thì sao -> có phải là sẽ cực kỳ khó khăn đúng không. Chính vì thế, cần phải có một giao thức chung và hiệu quả để làm điều này -> Serialization ra đời, thay vì sử dụng các giao thức riêng lẻ, Serialization cung cấp một cơ chế chung để chuyển đối tượng giữa các thành phần Java. Từ giờ các thành phần ứng dụng Java có thể sử dụng chung cơ chế này để giao tiếp và chia sẻ dữ liệu.
Bài viết hữu ích và chi tiết Cảm ơn bạn
@tuyen_dev e đang dùng docker trên win, mac hay linux đó?
hqua a vừa chạy lại 1 lượt ko thấy lỗi lầm gì, cho a xin screenshot từng lỗi đc ko?
@maitrungduc1410 anh ơi cả 2 lỗi này đều gây lỗi không chạy được app.
Lỗi npm ERR! missing script: serve
-Em phải thêm dòng "serve": "BROWSER=none react-scripts start" trong script
Lỗi "Browserslist: caniuse-lite is outdated. Please run next command npm update caniuse-lite browserslist"
-Em thêm " && npx browserslist@latest --update-db" để có thể chạy được
đọc xong vẫn chưa hiểu serialization với deserialization để làm gì
Bài viết rất hay. Cám ơn bạn!
Chào bạn, cảm ơn bạn đã quan tâm đến bài viết của Viblo Engineering. Ở 2 giải pháp này, mình xin phép đưa ra ý kiến đánh giá như sau:
Ưu điểm:
Nhược điểm:
Ưu điểm:
Nhược điểm:
Nếu yêu cầu trong dự án quan tâm đến hiệu suất và tối ưu hóa truy vấn thì tạo index cho mỗi loại dữ liệu tốt hơn. Ngược lại sẽ giúp giảm bớt sự phức tạp trong quản lý và mở rộng hệ thống. Nếu hệ thống của bạn cho phép thì bạn cũng có thể kết hợp 2 phương pháp bằng cách:
Không biết câu trả lời này đã giải đáp được thắc mắc cho bạn chưa nhỉ? Bạn cứ thoải mái đưa ý kiến và thảo luận thêm nha ^^
Oke ban
Chào bạn, bên mình chọn sử dụng cloud thay vì on-premise bởi vì một số lý do như sau:
Tóm lại, dùng cloud tiện lợi, đỡ tốn công sức và dễ scale hơn! Không biết câu trả lời này đã giải đáp được thắc mắc của bạn chưa nhỉ?
sao vào profile bạn chưa có bài viết nào mà đi đâu cũng thấy chê thế
@Fuzzy để đọc hiểu thì hiện nay cả các phần mềm lớn của nước ngoài cũng chưa làm được cái đó, vì gồng mình xử lý đống dữ liệu đã khá là chật vật rồi, nếu áp dụng mức độ cao kiểu LLM thì tốc độ kiểm tra sẽ chậm hơn rất rất nhiều. Trước kia có 1 bên của Isarel định làm kiểu đó nhưng cũng chìm không thấy tin gì thêm, và cũng chưa bên nào làm được với kiểu dịch từ Anh sang Việt mà vẫn tìm ra. Trường hợp paraphrase thì thực tế là điểm tương đồng sẽ giảm, không phải là 100% nữa mà còn 60-70% chẳng hạn, nhưng như vậy vẫn tính là trùng (chỉ bôi vàng chứ không bôi đỏ chót). Còn nếu paraphrase mạnh quá thì sẽ coi như là câu văn mới rồi, hiện tại thì sẽ bỏ qua.
Browserslist: caniuse-lite is outdatedcái này chỉ là warning e kệ nó nhé, ko nên tự upgrade 1 package riêng lẻ ko nằm ởpackage.jsonvề cái
BROWSER=none, thì a đã nói ở phần note cho các bạn dùng windows đó e ạcó 1 cách tù hơn đó là bạn có thể băm ký tự ra thành 1 mã hash và lưu vào phục vụ tìm kiếm
), nhưng tất nhiên lúc insert sẽ mất time để hash
Đầu tiên thì đa phần các CSLD hiện nay đều hỗ trợ tìm kiếm unicode. Thứ 2 là bạn cần tách biệt giữa chủ đề tìm kiếm nội dung text thông thường và tìm kiếm nội dung trong một file, ví dụ bạn đưa ra vấn đề tìm kiếm 1000 chương Cẩm Y Vệ thì nó sẽ thuộc vấn đề tìm kiếm nội dung file, sẽ không ai lưu 1000 chương cẩm y vệ vào database, họ sẽ lưu nó ra file để ở 1 server, và kể cả có lưu 1000 chương vào database dạng text hoặc CLOB thì nó vẫn không thể tìm kiếm theo cách thông thương, bạn sẽ phải thực hiện nhiều bước như loại bỏ ký tự hoặc từ thừa chỉ lấy các từ khóa chính sau đó map và đánh index ..vvv. Quay lại với việc tìm kiếm nội dung của các cột thông thường, thì nếu database không hỗ trợ unicode thì bạn sẽ có 4 cách. 1 là chuyển sang không dấu, 2 là dùng fulltext search, 3 là dùng 1 search engine, 4 là bạn có thể chuẩn hóa dữ liệu unicode thành dạng phân rã (canonical decomposition - NFD) để lưu trữ và tìm kiếm
cho những ai cài laragon 6.0 chạy wordpress 2024 trên máy win ver 23h2. Lỗi không dùng được. Hãy cân nhắc! Giải pháp thay thế là dùng docker
@roobinson phần check trùng thì bạn tìm từ giống nhau hay có đọc hiểu vậy nhỉ, vì có trường hợp người viết họ paraphare lại câu, nhưng bản chất vẫn là cùng một nghĩa
quá ngon
thanks thớt