Enterprise Vault Gets Vivisimo Search Engine

We hear Symantec is replacing Enterprise Vault's search engine. In a nutshell:

  • EV currently uses the aging AltaVista search engine. This has limited functionality, and support for it is being dropped. In 2014, AltaVista turns read-only: No new material will be indexed, and only searches will be allowed.
  • Symantec has been working on finding a replacement for the last few years.
  • Symantec recently decided to replace AltaVista with Vivisimo's Velocity search engine.
  • The new engine will be available in late 2011.

Symantec will have to decide how to integrate the new technology:

  • One option is rip and replace: Customers extract all content from the archive, uninstall EV, reinstall the new software, and then reingest all content.
  • However, this would be a major project for many customers--figure 12-24 months for larger customers!
  • Many customers are unhappy with EV, and would like to move to more modern technology. If Symantec chooses a rip-and-replace strategy, the upgrade efforts will be a catalyst for movement to more modern archiving technology.
  • Therefore, we doubt Symantec will go for rip and replace.
  • The other, more likely option, is that EV will support both AltaVista and Vivisimo searches. All new material will be indexed by Vivisimo; older material will keep the AltaVista indices. This will be a little inelegant at times; e.g., Vivisimo search queries are more powerful than those of AltaVista.

Customer issues:

  • As noted above, the time taken to rebuild indices with a search engine will be a problem for many larger organizations.
  • AltaVista's indices take very little space--around 12% of the material indexed. The new indices will need more space. Some search engines, such as those of Mimosa, have indices that take as much storage as the material being indexed [Note: Mimosa indices are really only 20% to 30% of the indexed material, although usually customers create a 100% shadow copy when indexing--see discussion in comments].
  • AltaVista has prevented a 64-bit version of EV. Vivisimo will permit this. A 64-bit version of EV will run faster and better than the current 32-bit version; e.g., it can use faster hardware, and it can use more memory.
  • Instead of Vivisimo Velocity, many customers would prefer a more mainstream search engine, such as Microsoft FAST, Autonomy Idol, or Google Search Appliance. Presumably Idol wasn't an option, because Autonomy is a major competitor to EV.
  • Vivisimo will allow more sophisticated searches (e.g., substrings, proximity searches) than have been possible with AltaVista.

... David Ferris, with many thanks to our well-connected source who requests anonymity

One Comment

  1. Posted April 6, 2010 at 1:12 PM | Permalink

    Vivísimo’s product is Velocity, not Veracity.

  2. dferris
    Posted April 6, 2010 at 1:23 PM | Permalink

    Thanks for the correction Colin, I’ll fix the text in the above posting
    –David

  3. dferris
    Posted April 9, 2010 at 2:12 AM | Permalink

    Integrating a new search engine is hard. Eg, Autonomy has a lot of problems integrating Idol with its Zantaz archiving technology. See, for example, the comments at http://www.archiving101.com/?p=77.

  4. Posted April 12, 2010 at 5:17 AM | Permalink

    The index engine from Mimosa NearPoint does not run at 100% size of the content it ingests. It is actually close to 20-25%.

  5. dferris
    Posted April 12, 2010 at 12:28 PM | Permalink

    Martin,

    Many thanks for correcting me about the size of NearPoint indices. That’s the second time I’ve been corrected on this bulletin. If I get corrected again, it’ll be a case of third time unlucky.

    My point was that EV customers may need to plan for substantially greater storage overhead as AltaVista is replaced. In the Mimosa case, as you say the indices themselves only take an extra 20% or 30% or so, rather than the 100% I asserted. On the other hand, when indexing most Mimosa customers choose to maintain an extra shadow copy for disaster recovery purposes, which takes as much space as the indexed content.

    So isn’t the overall thrust of my comment still valid in the case of Mimosa? Namely, that customers may need to plan for substantially greater storage overhead when a new indexing technology is involved?

    And yet, and yet…. perhaps it would have been better to give Autonomy Idol or FAST indices as examples–they’re pretty large I think, of the order of 100% of the indexed content. Can anyone help with this? As usual, requests for anonymity will be respected.

    –David

  6. Posted November 17, 2010 at 11:32 PM | Permalink

    Here is some finding after compare EV against Autonomy EAS.
    1, EV can not index Unix Files but EAS can.
    2, EV does not support Oracle as its native back end DBMS but EAS does.
    3, When eDiscovery and unstructured data search becomes more and more important for Enterprise Archiving, I don’t see any advantage that Symantec has to keep the leader position in the market. And not to mention that most of EV’s customers are mid-size firms, which explains why so far EV still does not support Oracle yet.
    4, When more and more multimedia content occupies the bandwidth, a powerful, scalable, easy to integrate and extend search engine becomes the essential point when enterprise plans its infrastructure.
    5,EV does support something that Autonomy does not especially on the Backup solutions as Symentec bought Veritas years ago. But is it really important anymore when Visualization becomes so popular today.

    Just some thoughts…

Post a comment

You must be logged in to post a comment. To comment, first join our community.