Reprise du message précédent :

Le big data n'aime pas trop les clusters ex les serveurs SAP Hana : http://global.sap.com/community/eb [...] ances.html
Tu as une base de données in memory qui prend plusieurs tera, si tu veux pouvoir écrire dedans il vaut mieux ne pas faire de deadlock sur une machine réseau...
 
Sur ce genre de serveur je pense que la débauche de processeurs n'est que là pour pouvoir adresser toute la RAM nécessaire.
 
SAP c'est pas un petit marché du tout c'est probablement près de 100% du CAC40 qui est sous SAP. (bon bcp de clients n'ont pas encore sauté le pas vers HANA et sont encore sous Oracle ou SQLServer, mais ça va venir)

Tu confirmes indirectement que le choix d'AMD de proposer le plus gros 2P possible est le bon, en fait
 
Un cluster, c'est un enchevêtrement d'arbres, et mieux vaut que chaque CPU soit le plus costaud possible pour la localité des données. Maintenant faudra voir le résultat vu qu'il semblerait que Naples soit constitué de 4 dies Zeppelin identiques aux R7.

C'est sûr, après les BDD in-memory c'est un peu à part (et ça fait baver vu les possibilités ). MS aussi s'y est mis pour SQL Server.

Le pas d'avant HANA, c'est plutôt SYBASEIQ .

ça n'a pas grand chose à voir SAP ECC est de l'informatique transactionnel, sur lequel on connectait des trucs compliqués (BW, BO ou syBase) pour réussir à faire de l'informatique décisionnel.
 
Sybase ne fait que le décisionnel, et ne produit pas de données (point de commandes clients, de factures ou d'ordre de productions)
 
Hana essaie de fusionner les deux (les transactions sont immédiatement exploitable / exploité en cube)

ça automatiserait les articles sur les retours de composants, et permettrait même à LDLC d'ajuster ces appros dés le début d'un buzz (bon ou mauvais ) sur un composant