Hỏi về form search và link đẹp

- Những trường (cột) trong câu query WHERE nên được đánh index, sẽ giảm được tải rất nhiều lên DB server.
- Những câu query được gọi thường xuyên và có kết quả giống nhau mỗi lần được trả về thì nên cache lại, thời gian cache tùy nhu cầu. Có thể xài Memcached, Redis, Aerospike,... Mình thấy PHP mọi người chủ yếu xài Memcached.
- Với Full text search, cao cấp hơn thì có thể xài Elasticsearch để scale out, để tăng performance và cache dữ liệu lớn, ví dụ product information, news,... lúc đó DB server chỉ write là chủ yếu, thường là cho các transactions.

 

Thanks bác, cho e hỏi đánh index là sao ạ? Thứ 2 e tính dùng phpfastcahe cache dạng file, vì trình chỉ tới đó nên chưa mở rộng nhiều

 

- Về index: https://www.tutorialspoint.com/mysql/mysql-indexes.htm
- Về phpfastcahe: Ý bạn muốn cache page? mình đoán là cache nội dung thành file html tĩnh và trả về cho user. Đây cũng là một cách tốt để giảm thời gian re render lại UI

 

content siêu chất thì auto đẹp trai thì title cùi cùi, page load không tối ưu, thẻ meta eo có, công nghệ mười mấy năm rồi, cả mấy năm không update hay url kiểu gì cũng lên top, còn content bình thường thì nó mới chú ý đến cái râu ria khác để chấm điểm.

Cứ đơn giản hóa SE coi như là nó bạn chấm điểm gái đi.

+ Mông to, vếu ngon , face xinh, dáng chuẩn thì thằng nào nhìn vô cũng auto mê rồi.
+ Còn mấy em khác không full kiểu mông to - face xấu, body ngon - face bình thường, face xinh - ngực lép thì lúc đó các bác đắng đo fai dựa thêm các tiêu chí khác để quánh giá thế thôi.

 

Ủa tưởng cache để cho GG index mới cần friendly url chứ tăng performance thì liên quan gì đâu?
Mà db em nhiêu gb, nhiêu records mà query 7s ghê vậy? Limit 1 lần lấy lên 50-100 records cho nó nhanh.
Anh mới test trên db của anh có hơn 54M records lấy ra 100 records mất khoảng 0.2 giây.

 

Vậy chắc do code rồi. Nếu có join các table thì sẽ chậm nhiều vì nó fetch theo cấp số nhân.
Mà anh làm mấy ngàn web rồi hình như chỉ có 2,3 web là nhiều hơn 6 table thôi chứ còn lại toàn 1 table chính chứa tất cả mọi thứ và khoảng 2,3 table phụ chứa cate, tags. Em làm hoành tráng quá, anh chịu ko nổi

 

Tối ưu hiệu suất thì khó nói, vì nó tùy vào bài toán cụ thể chứ ko thấy code + cấu trúc DB thì như thầy bói mù xem voi thôi. Nếu ko join thì em có thể dùng union để chuyển thành 1 câu query dài sẽ nhanh hơn là query 6 lần.
Fulltext dùng boolean mode cũng nhanh hơn natural language mode. Anh vừa thử query keyword dài 45 chars (gồm có 8 words) trên 1 table 30M rows mất hơn 0.2 giây xíu (chạy trên con laptop cùi).

 

Vậy sẵn e hỏi xin ý kiến của anh luôn, chứ e lập topic cũng lớn quá . Em có 1 db get từ imdb: nó gồm 2 table movie/tvshow, trong mỗi table sẽ có các column cơ bản của movie như: title/id imdb/desc/vote/star/duration... vấn đề ở đây e muốn hỏi khi code chức năng search một bộ phim theo title sẽ query tới 2 bảng movie/show rồi show ra là đã tối ưu chưa ạ? E đang nghĩ tới 1 phương án là khi user query thì mình sẽ query tới imdb lấy kết quả -> lấy id imdb-> từ id query tới db của mình. Hồi giờ e chưa làm việc với db nhiều nên xin ý kiến anh.

 

Em là newbie ko dám to mồm cơ mà thấy cái phương án của bro k đc đúng cho lắm. Mình đã có db rồi sao ko search trong db của mình mà lại đi query sang imdb chỉ để lấy id rồi lại quay về query db của mình tiếp Hơi khó hiểu mục đích của đoạn này

 

Chủ yếu bạn design DB và query như thế nào thôi. Post TABLE schema và câu query mẫu của bạn lên đây xem.

Còn chuyện bạn query qua imdb hay không là do bạn đánh giá tốc độ. Nhưng mình nghĩ không nên, vì bạn phải thực hiện nhiều lần truy vấn và phải thụ thuộc vào yếu tố bên ngoài.

 

vì e với db lớn việc search với title sẽ gây chậm, thay vào đó mình search title với bên thứ 3, lọc ra id imdb rồi từ đó có query trực tiếp tới db bằng id sẽ nhanh hơn và giảm tải tới db ?

Code:

CREATE TABLE `data` (
    `id` INT(11) NOT NULL AUTO_INCREMENT,
    `imdb` VARCHAR(50) NOT NULL COLLATE 'utf8_unicode_ci',
    `created` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    `type` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
    `name` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
    `year` YEAR NOT NULL,
    `rating` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
    `genre` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
    `releaseday` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
    `poster_big` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
    `poster_small` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
    `cast` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
    `director` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
    `mpaa` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
    `description` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
    `plot` LONGTEXT NOT NULL COLLATE 'utf8_unicode_ci',
    `vote` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
    `runtime` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
    `trailer` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
    `comment` LONGTEXT NOT NULL COLLATE 'utf8_unicode_ci',
    `tag` LONGTEXT NOT NULL COLLATE 'utf8_unicode_ci',
    PRIMARY KEY (`id`)
)
COLLATE='utf8_unicode_ci'
ENGINE=InnoDB
AUTO_INCREMENT=1
;

Câu query mẫu của e đây ạ, e dùng pdo, với search title

với search trực tiếp ID imdb

 

- Câu query bạn đang SELECT * (all), nếu được, nên select những field cần thiết.
- Mệnh đề WHERE có LIKE "%key%", cái này làm cho việc đánh index mình recommend lúc đầu vô nghĩa. Nếu là "key%" thì còn nên giữ, không thì xoá index đó đi nếu bạn đã tạo.

=>
- Bạn nên đọc qua tài liệu này từ MySQL: https://dev.mysql.com/doc/refman/5.7/en/fulltext-search.html
- Hoặc, bạn có thể deploy 1 Elasticsearch node để load toàn bộ title và ID lên, khi user search, bạn sẽ thực hiện full text search trên Elasticsearch và lấy ID rồi query xuống MySQL để lấy detail content. Hoặc bạn có thẻ load all nội dung lên Elasticsearch để không phải query xuống MySQL nữa nếu có đủ đĩa cứng. Vấn đề là bạn phải đánh giá khi nào cần resync data giữa MySQL và Elasticsearch

 

Đối với phim e chỉ cho search 1 field title name thôi ạ , không cho mấy field cast / director = > mấy thành phần search cái này cũng hiếm mà chỉ tổ làm chậm db của mình . Ý tưởng của e vẫn cố tránh full text search tới db, mà là query tới column chứa id imdb, cho nên e mới nảy ra idea query tới thằng imdb => có result id imdb => query id tới db mình . Sau khi có result từ search e sẽ cache thằng này và lần sau ko query tới imdb nữa.

 

Được em ạ, ý tưởng của em hay lắm, cố gắng lên. Anh đọc xong ý tưởng của em anh cũng chóng mặt xỉu mất 1 lúc giờ mới tỉnh dậy trả lời nè

Giỡn xíu thôi. Thật ra 2 table movies và TV Series gom vào thành 1 vẫn dc mà, phân biệt = 1 field Type là OK. IMDB có mấy triệu records chứ đâu bao nhiêu, dùng fulltext search cực nhanh. Em đang bị đi đường vòng để lấy ra movieID rồi query trên DB theo kiểu where ID = $movieID, vừa tốn công code vừa không an toàn vì mình phụ thuộc thằng khác. Mà nói kiểu này thì chắc là chưa dùng fulltext rồi. Thử đi, bao nhanh.

 

ủa mắc gì tránh fulltext, tốn thêm tầm gấp 4 lần dung lượng data không fulltext thôi chứ có nhiêu đâu.
Mới check lại cái DB con của IMDB có hơn 300K movies thì thấy có mấy chục Mb, nếu chuyển sang fulltext thì tầm vài trăm Mb là cùng.

Bổ sung: phần bôi màu đỏ là quá sai lầm nhưng mà không chỉ nữa, kẻo thêm đối thủ cạnh tranh thì mệt

 

thx anh, để e thử ạ

 

Site em đang làm như thế, nhưng khổ nỗi ko biết code mà chỉ bác

 

Bác cũng làm site movie luôn hả??