Nghề lập trình là cái nghề so đo, tính toán, cân nhắc thiệt hơn nhiều nhất trong các nghề mà tôi biết. Tại sao ư? Tại vì tôi chưa làm nghề gì khác ngoài những việc liên quan đến lập trình =))) Nhìn lại, từ khi bước chân vào nghề là đã phải một đống lựa chọn được đưa ra: Theo hệ thống thông tin hay theo kỹ thuật phần mềm, theo Java hay theo C#, theo Web hay theo App, Theo Backend hay là Frontend. Đó mới chỉ là bước khởi động để lựa chọn vào nghề, vào nghề rồi thì lại một đống công nghệ xuất hiện cạnh tranh với nhau, thay thế nhau hoặc xâm lấn chức năng của nhau. Thế là một loạt các diễn đàn xuất hiện để tranh cãi, phản biện, bao biện với nhau về những cái mình đang làm.Ngày tôi mới đi làm cũng vậy, thông tin chưa được nhiều, và tôi cũng chưa đủ kiến thức để có cái nhìn đúng đắn, đứng trước hàng loạt những lựa chọn về công nghệ cho bài toán cần triển khai, cái đầu tiên tôi phải đối mặt là xây dựng Database với SQL hay là NoSQL. Ngày ấy NoSQL nổi lắm, cái gì cũng NoSQL, quảng cáo thì bá cháy, nhanh, gọn, dễ làm, và hiển nhiên nó chiếm trọn tâm trí của một cậu chàng lập trình viên trẻ ưa cái mới như tôi. Cũng ngày đó, chúng tôi nhận được một dự án làm hệ thống gợi ý cho khách hàng bán đồ trang sức bên Đức, họ lúc đó có đến 60 stores trên toàn thế giới, việc của chúng tôi là phân tích hành vi của khách hàng và đưa ra các box gợi ý các sản phẩm. Để làm được việc ấy thì chúng tôi cần có một database lưu thông tin các sản phẩm về nhẫn, kim cương, vòng, … Ban đầu khách hàng đưa chúng tôi một tập thông tin các sản phẩm mặc định (tên sản phẩm, giá, màu sắc, option, …) để chạy thử trên một store trước khi lên production và rollout ra 60 stores trên toàn thế giới. Đề bài cơ bản là vậy, chả phải nghĩ nhiều, tôi tống hết các thông tin đó vào trong MongoDB, ở nơi đó, mỗi document là một sản phẩm chứa đầy đủ hết thuộc tính của một sản phẩm trang sức: Tên sản phẩm, mô tả sản phẩm, danh mục của sản phẩm, giá sản phẩm, màu sắc, loại kim cương, …Ấy thế là trong 3 tháng, chúng tôi đã xây dựng xong một hệ thống recommendation (phần nhiều công việc nằm ở ở thuật toán gợi ý). Demo thành phẩm với khách hàng, các ông Tây lông khá là chim ưng, họ đã đồng ý cho chúng tôi triển khai hệ thống lên production và rollout cho 60 quốc gia, đồng thời yêu cầu đội IT bên họ cung cấp đầy đủ dữ liệu để chúng tôi có thể triển khai hệ thống một cách độc lập. Một sự support rất tuyệt vời, và cờ đến tay thì anh em phất thôi, thế là lúc ấy, tôi hừng hực khí thế vào triển khai dự án với một sự tự tin mà đến bây giờ tôi vẫn chưa có được bằng ngày đó
Nhưng thực sự, đời không như là mơ và mình cũng đang không có làm thơ. Từ Demo lên Production nó là một cái gì đó rất là khó tả. Khi Demo, mỗi product_id là một sản phẩm duy nhất, tại đó có đầy đủ các thông tin mô tả sản phẩm, nó là một thứ rất phẳng, gọi product_id vào rồi trả ra một đống thông tin như giá rổ, mô tả là OK. Nhưng, khi lên Production, mọi thứ nó lại khác hẳn. Mỗi product_id nó sẽ có các thông tin cơ bản, và tuỳ vào option mà user lựa chọn (màu sắc, loại đá, hình dáng, …) thì nó sẽ tạo ra một sản phẩm riêng hay tạm gọi là ra một item. Và cái item này mới là cái cuối cùng mà hệ thống recommendation này cần phải trả ra, dĩ nhiên giá nó cũng thay đổi chứ không phải theo giá base của product_id. Cái giá này mới là cái đau đầu, vì nếu gợi ý ra giá sản phẩm bị sai thì chết đòn với nhà đầu tư
Đó đó, chắc là bà con đã hiểu vấn đề cần giải.Đề đã đưa ra thì mình ngồi luận thôi, bám theo con MongoDB NoSQL mà giải thì phải làm thế nào. Một quick solution được nhả ra là flatten hết cả đi, từ một product_id, cho kết hợp với tất cả option rồi tính trước giá rổ, xong đưa vô Mongo, gọi cái là ra, izy boy, khà khà =))) Ấy chà chà, ngồi tính toán lại chút nào. Chúng ta có khoảng 20k product_id, 10 màu sắc, 30 loại stones, 10 loại stone shape 10 loại carat, 20 styles trang sức, … còn nhiều option nho nhỏ khác nữa, tính sơ sơ xem nào mình sẽ có khoảng 20k * 10 *30 * 10 * 10 * 20 = 12 tỉ items
ối zồi ôi thực sự !!! À quên, đấy là chưa nhân với 60 stores trên khắp thế giới, kết quả thế nào thì bạn tự tính nhé. Một con số điên rồ thực sự !!!Chả lẽ bó tay, tiền đến tận miệng rồi mà không hớp được. Khi gặp vấn đề như này tôi thường có tư duy về gốc chứ không cố đấm ăn xôi nữa. Câu hỏi đặt ra là liệu NoSQL có phải là con đường nên theo ở bài toán này? Và tiếp theo là đội IT bên khách hàng đang xử lý vấn đề này như thế nào? Cũng chả biết nói gì hơn ngoài sự may mắn, đó là đội IT của khách hàng cũng là mấy bác đang ngồi ở Việt Nam, thế là khăn gói quả mướp lên đường, tôi sang chày cối xin ngồi rồi ăn nằm bên đội IT của khách hàng để hiểu được nghiệp vụ họ đang xử lý là gì, nói đúng hơn là học lỏm, cũng may sao họ support rất nhiệt tình
Và thế là sau màn đi du học về, tôi ngồi kỳ cục lắp ghép để có được 120 dòng lệnh SQL cùng với hệ thống DB chuyển đổi sang MySQL để Join, Query các kiểu. Ở hiền thì ắt gặp lành, sự may mắn đã đến và tôi đã giải quyết được vấn đề hóc hiểm lúc đó và golive thành công cho khách hàng và cũng chỉ tốn có 4GB data và độ chục cái table. Với tôi lúc đấy, đó quả là một công trình vĩ đại
Và cái đống di sản 120 câu SQL đó sống yên ổn trong 3.5 năm cho đến khi khách hàng chuyển đổi và không thuê dịch vụ của chúng tôi nữa. Ấy, sự khờ khạo lúc đó khiến tôi lựa chọn một thứ rất là trend và cũng đã phải đâm đầu vào đá với lựa chọn của mình. Nhưng nghĩ lại thì tôi cũng không tiếc lắm vì lựa chọn lúc đó, ít ra còn có câu chuyện để mà nói và cũng rèn luyện được khả năng giải quyết vấn đề của mình. Nói đi cũng phải nói lại, may mắn vì được ngồi cùng đội IT của khách hàng để hiểu về nghiệp vụ rồi góp nhặt solution, chứ nếu lúc đó cứ chat rồi call qua lại thì không biết lúc nào sản phẩm của chúng tôi mới có thể golive được
Hi vọng câu chuyện trên có chút giá trị giải trí cho mọi người
Cảm ơn mọi người, tôi là Huy Đê Tê!
Ngành IT