我爲一家網絡公司工作,我們目前使用高度修改的OSCommerce版本作爲我們的主要電子商務應用程序,但最近我們已經接觸到了一些擁有超過200萬個單獨產品模型的公司想要在網上銷售。如何處理2百萬個產品
本質上,我的問題是 - 是否有任何預先構建的PHP/MySQL購物應用程序能夠很好地處理這些許多產品,還是我在這方面運氣不佳?我是否需要創建一個自定義應用程序?我在這裏有什麼選擇?
nosql數據庫會比MySQL更好嗎?
我爲一家網絡公司工作,我們目前使用高度修改的OSCommerce版本作爲我們的主要電子商務應用程序,但最近我們已經接觸到了一些擁有超過200萬個單獨產品模型的公司想要在網上銷售。如何處理2百萬個產品
本質上,我的問題是 - 是否有任何預先構建的PHP/MySQL購物應用程序能夠很好地處理這些許多產品,還是我在這方面運氣不佳?我是否需要創建一個自定義應用程序?我在這裏有什麼選擇?
nosql數據庫會比MySQL更好嗎?
您不清楚這是200萬件產品的庫存還是200萬件他們想出售的單件產品。無論哪種方式,傳統的SQL數據庫應該能夠很好地處理它,儘管這完全取決於架構的設計方式等。儘管我已經聽說過關於Magento的好東西,但我不確定已有的解決方案。
您一定想要構建定製解決方案,並且您一定要收取比平常更多的費用,因爲存在很多風險和盡職調查需求。
至於你的架構,使用NoSQL是可能的,並且在電子商務中使用NoSQL背後有一些令人信服的理由 - 主要原因是它是無模式的,並且如果你有大量類別和大量產品需要以不同的方式銷售(即,您銷售的計算機與銷售手錶的方式不同),因爲產品屬性不同,管理數據庫的複雜性變得非常重要。
此視頻將向您展示紐約市真正具有前瞻性的創業公司正在做什麼。他們正在使用MongoDB作爲他們的整個產品數據庫。該視頻應該是一個真正的大開眼界,因爲它概括了很多在MySQL中陷阱的大的電子商務網站,和NoSQL的改變遊戲規則的潛力很多:
http://engineering.shopopensky.com/topics/mongodb
至於處理付款,你肯定不希望將這些存儲在NoSQL中。將您的用戶,會話和支付數據保存在MySQL中,並確保它具有高度安全性。下面是確保會話一個偉大的(即使舊)一塊PHP應用程序:
http://www.troubleshooters.com/codecorn/php/persist.htm
作爲一個說明,這最後一個環節將幫助你理解理論更好。大多數PHP框架支持這種類型的開箱即用處理。 CodeIgniter,Yii和ZendFramework都是最好的。
FWIW,對於MySQL來說,200萬條記錄並不是什麼大問題,我認爲通常保留1個數據庫將使您的應用程序更容易維護。就個人而言,我不認爲NoSQL在這裏是一個好計劃。有趣的閱讀(如果有點老)可以在這裏找到,重新:Facebook的使用MySQL:http://blog.facebook.com/blog.php?post=7899307130 – jvenema 2011-01-26 21:05:18
感謝您的鏈接! – 2011-01-26 22:01:46
基本上我的問題是 - 是否有要處理這麼多的產品擺好
號如果有這些公司2,000,000的產品將使用它的任何預置的PHP/MySQL的購物應用。
我需要創建一個自定義應用程序嗎?
您已擁有。您以OS Commerce作爲基礎開始並在其上構建自定義應用程序。你可能不會認爲它是一個應用程序,但它是。
我在這裏有什麼選擇?
接受,你需要一個像樣的IT /開發團隊這項工作追去,如果這個成本驢和R & d是值得在此之後的新業務去。
nosql數據庫會比MySQL更好嗎?
不,但MySQL數據庫也不會比「nosql」數據庫更好。
根據預算,Magento Enterprise可能是一個很好的解決方案。 (我不是說要出售它,我不是合作伙伴)。您可以構建解決方案或讓託管公司幫助您解決問題。 Rackspace是首屈一指的合作伙伴託管公司,非常擅長將這些解決方案放在一起。有很多數字在起作用,例如峯值同時連接,每小時綜合瀏覽量,每小時事務處理等。您希望查看具有至少2個MySQL服務器(主/從複製)和多個負載均衡器後面的前端服務器。看一看nginx,而不是Apache。您還需要查看用於緩存的memcached apc &。像這樣的設置將會有很長的路要走。如果設置正確,Magento Enterprise可以輕鬆處理這些許多產品。重要的是要記住的是,定製解決方案不需要開發 - 它將需要設計。
爲了迴應Magento Enterprise的建議,我們最近爲我們的網站實施了這個應用程序,該應用程序攜帶約150,000多個SKU。我們也從一個廣泛定製的osCommerce版本遷移。由於企業系統運行速度緩慢以及缺乏實施文檔,我們的經驗是挫折感和項目延遲。正因爲如此,我們實際上無法使用許多企業版功能。
該應用程序由於缺乏文檔和我們親身體驗的Varien支持團隊的響應緩慢而臭名昭着。模板系統似乎只是部分完整,沒有特別深思熟慮。您的問題的迴應者之一Alan Storm,實際上是我們團隊的救星,他的書面教程和慷慨的stackoverflow.com答案。
我的建議是事先對Magento Enterprise平臺進行廣泛的研究 - 它與社區版本不一樣。正如Bob Brodie在上面所提到的那樣,服務器的要求和設置並不是因爲心臟不夠,也不便宜。研究可用的速度增強選項 - 您將需要它們,服務器管理費用,考慮學習曲線以及將增加到項目時間表的額外時間--Magento與osCommerce有很大不同 - 並且最重要的是找到一個可靠的,經驗豐富的Web主機然後再支付12,000美元的一年許可費用。
我只是好奇,如果有人認爲這個設置可以做到這一點。 magento社區使用反向代理(可能爲varnish)和memcached作爲應用程序的緩存。在產品頁面上沒有動態內容(因爲它可以在與緩存響應進行自定義交互時呈現)來將應用程序的請求保持爲絕對最小值。 使用負載均衡的nginx服務器。
你也可以實現更多結構化的數據庫維護和優化程序作爲一個單獨的應用程序。
也許你可以做一些相當激進的事情,但價格相當便宜(我猜那些擁有200萬產品的傢伙對你和我來說有着不同的想法),將銷售,稅收和銷售規則模塊更改爲不太靈活的東西,但是更高效。
我不知道似乎是最好的方式給我。每年支付magento EE的費用爲 誇耀表現。
一來這類產品負載的最佳答案的(並且,順便說一句,我們使用了一個)是https://magento.stackexchange.com/questions/459/running-magento-in-an-aws-environment
我們在Amazon Web服務上運行一個自定義的Magento社區(1.9)服務器使用RDS產品的豆莖環境,用於緩存的redis & S3 - >與Magento相關的媒體的CDN。現在還很早,但迄今爲止我們還沒有發現真正的問題。預計開發時間...也許一個星期左右,從本地mysql/cache/apache/php的VPS轉移?
不要過度建築。 200萬聽起來很多,但任何體面的數據庫/硬件組合都可以在不損失汗水的情況下處理200萬條記錄(假設您有一些體面的索引)。請看這裏re:每天插入一百萬條記錄:http://forums.mysql.com/read.php?61,44239,44251#msg-44251 – jvenema 2011-01-26 21:10:50